[systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

Pekka Paalanen ppaalanen at gmail.com
Fri Mar 20 08:18:35 UTC 2020


On Thu, 19 Mar 2020 17:47:30 +0100
Paul Menzel <pmenzel+systemd-devel at molgen.mpg.de> wrote:

> Dear systemd folks,
> 
> 
> I am using Debian Sid/unstable with systemd 245.2 and Weston 8.0.0.
> 
> I amtrying to start a graphical desktop as soon as possible. Currently, 
> I use Weston, but unfortunately accessing `/dev/dri/card0` it gets a 
> permission denied error. The Weston service unit is ordered after 
> `systemd-logind.service`.
> 
> Weston now fails to start, because it gets a permission denied error 
> accessing `/dev/dri/card0` [1][2].
> 
>      drmModeSetCrtc(backend->drm.fd, output->crtc_id, 
> scanout_state->fb->fb_id, 0, 0, connectors, n_conn, &mode->mode_info);

Hi,

if you get permission error from drmModeSetCrtc() call, then it has
nothing to do with file system permissions. The device node was already
opened successfully. Most likely the open DRM device file description
does not have the DRM master status.

> 
> Right before Weston starts, the permission and ownership are like below.
> 
>      $ ls -l /dev/dri:
>      insgesamt 0
>      crw------- 1 root root 226,   0 Mär 19 17:29 card0
>      crw------- 1 root root 226, 128 Mär 19 17:29 renderD128
> 
> After udev applied the rules, it looks like below, meaning users in 
> group `video` are allowed to access the device.
> 
>      $ ls -l /dev/dri
>      insgesamt 0
>      drwxr-xr-x  2 root root         80 Mär 19 17:29 by-path
>      crw-rw----+ 1 root video  226,   0 Mär 19 17:29 card0
>      crw-rw----+ 1 root render 226, 128 Mär 19 17:29 renderD128

If you use logind, then logind runs as root and is used to open the DRM
device node on behalf of weston, so these file system permissions
should be irrelevant.

However, logind can revoke DRM master status from weston, and possibly
even open the device without granting the DRM master status I guess.

Not having DRM master status will cause drmModeSetCrtc() and any other
KMS state change to fail, quite likely with a permission error.

> 
> Is there a way to order a service in such a way, that it’s guaranteed 
> that udev rules to devices were applied?

However, udev rules can affect which DRM device node Weston attempts to
use. But since it already opens the right(?) one, I don't think udev
rules change anything.

> A small script applying permissions and ownership manually in 
> `ExecStartPre=` seems to work around the (graphics) issue.

I'm guessing this just causes enough of a delay to hide the race
somewhere else.


Thanks,
pq

> 
> If it cannot be solved with ordering, what would you suggest?
> 
> [1]: https://gitlab.freedesktop.org/wayland/weston/issues/382
> [2]: 
> https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/kms.c#L741
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200320/073bae75/attachment.sig>


More information about the systemd-devel mailing list