Bug 967230 - /dev/vfio/vfio has 600 permissions, should be 666 (fix is queued for 3.10)
Summary: /dev/vfio/vfio has 600 permissions, should be 666 (fix is queued for 3.10)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-25 20:01 UTC by Cole Robinson
Modified: 2013-06-14 04:49 UTC (History)
6 users (show)

Fixed In Version: kernel-3.9.5-301.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-14 04:49:41 UTC
Type: Bug


Attachments (Terms of Use)

Description Cole Robinson 2013-05-25 20:01:17 UTC
/dev/vfio/vfio has 600 permissions, but in order for libvirt to be able to use it with default config, it needs to be 666. 3.10 already has a fix queued up, could it be backported to current F19?

commit 664e9386bd05dbdfecfb28d6cf2fde983aabc65c
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Tue Apr 30 15:42:28 2013 -0600

    vfio: Set container device mode
    
    Minor 0 is the VFIO container device (/dev/vfio/vfio).  On it's own
    the container does not provide a user with any privileged access.  It
    only supports API version check and extension check ioctls.  Only by
    attaching a VFIO group to the container does it gain any access.  Set
    the mode of the container to allow access.

Comment 1 Cole Robinson 2013-06-11 15:35:08 UTC
Will also need:

commit 9a6aa279d3d17af73a029fa40654e92f4e75e8bb
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Wed Jun 5 08:54:16 2013 -0600

    vfio: fix crash on rmmod

Comment 2 Josh Boyer 2013-06-11 16:07:38 UTC
We can grab those, but is there a reason they aren't CC'd to stable?  Particularly the second one?

Comment 3 Cole Robinson 2013-06-11 16:15:33 UTC
Alex, see Comment #2, is there a reason these VFIO bits aren't heading for kernel stable tree?

Comment 4 Alex Williamson 2013-06-11 16:29:31 UTC
I don't see that they meet the rules for stable.  It's not a critical bug as far as the kernel is concerned.  Note that both of these are going in during the 3.10 development phase, so there is no case of a released upstream kernel including one without the other.

Comment 5 Josh Boyer 2013-06-11 19:19:15 UTC
(In reply to Alex Williamson from comment #4)
> I don't see that they meet the rules for stable.  It's not a critical bug as
> far as the kernel is concerned.  Note that both of these are going in during
> the 3.10 development phase, so there is no case of a released upstream
> kernel including one without the other.

Ah.  I see.  I should have looked more first.  I thought the rmmod fix was a stand-alone issue.

I've grabbed both for F19.

Comment 6 Fedora Update System 2013-06-11 21:41:22 UTC
kernel-3.9.5-301.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.9.5-301.fc19

Comment 7 Fedora Update System 2013-06-12 19:12:29 UTC
Package kernel-3.9.5-301.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.9.5-301.fc19'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10689/kernel-3.9.5-301.fc19
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2013-06-14 04:49:41 UTC
kernel-3.9.5-301.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.