Re: [systemd-devel] How to give users permissions to /dev/kfd

[Mantas Mikulėnas]

On Sat, Oct 14, 2017 at 1:07 AM, Tom Stellard  wrote:

> On 10/12/2017 09:04 PM, Mantas Mikulėnas wrote:
> > On Fri, Oct 13, 2017, 00:30 Tom Stellard > wrote:
> >
> > Hi,
> >
> > The amdkfd kernel driver exposes the /dev/kfd device file for doing
> gpgpu
> > computing on AMD GPUs, I would like to setup the permissions on this
> device
> > file, so that regular users can access it.  I think it makes sense to
> > try to copy what is being done for the other GPU device files, like
> /dev/dri/cardX.
> > I can see the udev rules for these /dev/dri/cardX, but on my system
> it looks like
> > something is giving users access to these files using  access
> control lists
> > (acls), but I'm not sure where the acls are being modified.  Is
> systemd only responsible
> > for the udev rules or is there something else in systemd I need to
> modify to
> > get the acls set correctly?
> >
> >
> > udev applies these ACLs to all devices tagged with TAG+="uaccess" from
> udev rules.
> >
> > (The tagging is kind of an internal detail and your rules are supposed
> to use ENV{ID_this_and_that}, but... for personal use it works well enough.)
> >
> > Just make sure you get the rule ordering right, I think
> 71-something.rules is a good place. I can't check right now, might be
> remembering wrong.
> >
>
> Thanks.  I've been experimenting with this, and I noticed that the ACLs are
> not set when I login to the machine via ssh.  Is there something else I
> need
> to do to get these ACLs enabled for ssh sessions?
>

No, it's only available for local sessions (ones which systemd-logind
considers "local" + "active"). I think the idea is that console users
automatically get more privileges in general.

*(To update my last mail, I *think* the actual ACL setting is done by both
udev (when the device first shows up) and systemd-logind (when sessions are
switched).)*

For SSH-only usage, use traditional groups (e.g. add yourself to the
"video" group). To assign group ownership to /dev/kfd, use GROUP="foo" in
udev rules.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Conflicts no longer working as expected during boot in v235

[Michael Biebl]

Ok, the problem is apparently happening because spice-vdagent triggers
the start of a service via a udev rule.

In a minimal Debian buster installation, which does not exhibit the
problem, I can trigger the problem after adding the following two
files:

# cat /etc/systemd/system/sleep.service
[Unit]
Description=Sleep for 5 seconds

[Service]
Type=oneshot
ExecStart=/bin/sleep 5

ACTION=="add", SUBSYSTEM=="net", ENV{SYSTEMD_WANTS}="sleep.service"


# cat /etc/ude/rules.d/70-test.rules
ACTION=="add", SUBSYSTEM=="net", ENV{SYSTEMD_WANTS}="sleep.service"

After a reboot, now suddenly chrony and systemd-timesyncd are *both* running.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Conflicts no longer working as expected during boot in v235

[Michael Biebl]

After investigating this further, I can also reproduce this with older
systemd versions (tested with v232 and v234).

For the problem to be reproducible, I had to install spice-vdagent in
the libvirt/KVM instance.
Haven't quite figured out yet how this influences the start of
chrony.service and systemd-timesyncd.service. So help still welcome.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel