Bug 958517

The Product for this issue was incorrectly set to opensuse.org and not Tumblweed. I corrected that.

In addition to Tumblweed this issue also affects Leap. The vhba-kmp-default module is correctly pulled in as a dependency by cdemu-daemon but one needs to manually load it as otherwise the daemon won't start.

There are two ways a module can be loaded:

 1. hardware discovery, so the kernel triggers an udev event
    to find something for e.g.
    pci:v00001186d00001300sv0000sd0000bc0000sc0000i0000
 2. a process opens a device node for which no drivers is
    known, so the kernel triggers an udev event to find
    something for e.g. char-major-10-229.

There are two ways a device node can appear:

 3. a kernel module was loaded that creates a device node

The astute reader will have noticed: There is a circular dependency between module loading and a device node being present, for any module that pertains to non-auto-discoverable extensions (e.g. fuse, vhba, sonypi). One can either break the circle

 4. by providing device nodes staticly ahead of time, or
 5. by loading modules unconditionally

Up to about 2005, method #4 was used. Thousands of device nodes were provided by a big RPM package. About 2005, /dev was switched to be populated dynamically. As a result, #2 could not be exercised anymore, and so workaround #5 was employed. But loading modules unconditionally uses precious kernel memory before you actually request the feature, which is also bad.

About 2011, kmod gained "modules.devname" support, which is a static list specifically for such modules. Once you install vhba-kmp-default, /lib/modules/$xyz/modules.devname gets updated to contain an entry for vhba. With that entry, /dev/vhba is created on boot, which makes it possible to use #2.

Unfortunately, this only takes effect on the _next boot_ because... bug #1220303 . But as far as vhba is concerned, there is no bug.

Thanks for the detailed explanation, Jan. I understand this a lot better now and you are right, the package correctly uses modules.devname to make the module loadable.

Sadly, there still seems to be a chicken and egg problem that I'd consider a bug in the way that cdemu-daemon interacts with that module then. cdemu-daemon is meant to run as a user, and it places a udev rule that adds the "uaccess" tag so that users with a valid session can access the module. However, as I see it, the udev rule only gets applied once the module is loaded. After boot, the device file looks like this:

crw------- 1 root root 10, 170 25. Feb 18:36 /dev/vhba_ctl

In result, the user is is unable to access /dev/vhba_ctl to trigger loading of the module. Startup of the daemon running in user context fails with the following error:

cdemu0: Kernel I/O: failed to open control device /dev/vhba_ctl: Keine Berechtigung!

This is not a group membership issue, as you can see the file is owned only by root and there's no ACL set. Explicitly loading the module triggers the udev rule and the file has permissions that make it accessible:

crw-rw----+ 1 root root 10, 170 25. Feb 19:20 /dev/vhba_ctl

I strongly assume there is some mechanism that allows setting the proper permissions / ACLs on the device file from the start. But the way that this file is currently configured via the vhba-kmp-* / cdemu-daemon packages seems buggy to me. Sadly, even after having learnt all of those interesting details from your last post on this bug, I still seam to be lacking the proper internet search skill to figure out how this is meant to work properly.

I think I figured it out. It seems the udev rule is missing a `OPTIONS+="static_node=vhba_ctl"` to ensure that the permissions are already applied before the module is loaded.