On Thu, Apr 18, 2019 at 11:05:28AM -0400, Aaron Conole wrote: > On some systems, it's possible that the initialization of the misc chardev > associated with /dev/vfio/vfio is delayed. This happens on machines with > large numbers of cores (at least 88+). If this delay exceeds the time > required for ovs-vswitchd to call the dpdk initialization routine, the > permissions won't be updated and the open call will return EACCES. > > To fix this, we explicitly allow global open. This means any user may > open() the vfio device before the vfio modules are initialized, thus > triggering a module load. The applications (including ovs-vswitchd) > would be pended while the module loads. This should be safe, as any user > may open the vfio device once the module is loaded anyway, since the. > module rewrites the permissions as 0666. > > Signed-off-by: Aaron Conole <[email protected]> > --- > rhel/usr_lib_udev_rules.d_91-vfio.rules | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/rhel/usr_lib_udev_rules.d_91-vfio.rules > b/rhel/usr_lib_udev_rules.d_91-vfio.rules > index 8e34b2a2b..c0504ab5a 100644 > --- a/rhel/usr_lib_udev_rules.d_91-vfio.rules > +++ b/rhel/usr_lib_udev_rules.d_91-vfio.rules > @@ -1 +1,2 @@ > ACTION=="add", SUBSYSTEM=="vfio*", GROUP="hugetlbfs", MODE="0660" > +ACTION=="add", SUBSYSTEM=="misc", KERNEL=="vfio", MODE="0666"
Wouldn't be better to fix this at the module to fix the permissions before whatever is taking long to initialize? fbl _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
