Re: [systemd-devel] How to stop systemd-udevd reading a device after dd
On Thu, Oct 12, 2017 at 7:01 PM, Akira Hayakawa wrote:
> I have a device /dev/sdb1 and let's trace the block request by blktrace
>
> $ sudo blktrace -d /dev/sdb1
>
> When I write 4KB using dd
> $ sudo dd if=/dev/zero of=/dev/sdb1 oflag=direct bs=4k count=1
>
> The block trace (after blkparsed) is write request as expected
> 8,17 22 0.03171 5930 Q WS 2048 + 8 [dd]
>
> followed by a unexpected read from systemd-udevd
> 8,17 72 0.001755563 5931 Q R 2048 + 8 [systemd-udevd]
>
> My first question is what is: this read request?
>
When a device node is closed for writing, the kernel generates a 'change'
uevent for it. This prompts udev to re-read filesystems and update its
cache of labels, UUIDs, and other information. Tools like `lsblk` or
/dev/disk/by-{id,uuid,label}/* use the udev database.
And I want to stop the read request because it makes it difficult to test
> kernel code.
> So the second question is: how can I stop the read request?
gparted seems to achieve this by masking all .rules files it can find (by
creating 0-byte versions under /run/udev/rules.d).
Not sure what else to recommend. I thought there used to be inhibit mode
under `udevadm control`, but I can't find it anymore.
> Actually I found this behavior when I test my module https://github.com/
> akiradeveloper/dm-writeboost
> Since I need to create/remove devices during the tests, there is no choice
> to stop udev.service.
>
The kernel itself adds/removes device nodes under /dev. Udev only manages
auxiliary stuff like symlinks (like /dev/disk/by-*), permissions, and such.
So you *could* survive without udev in case of emergency.
--
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to give users permissions to /dev/kfd
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.
--
Mantas Mikulėnas
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to give users permissions to /dev/kfd
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? Thanks, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-coredump gets terminated during shutdown
Hi All, I have an issue with the standard unit file: ./units/systemd-cored...@.service.in In my use case if the main application crashes twice in 2-minutes, the system will reboot into a recovery environment. I'm using systemd-coredump to capture the coredump files, but the problem is that if the reboot is triggered, then the coredump process is killed during shutdown before the coredump has been written to disk. First of all, I'm having trouble correcting this behaviour. The systemd-coredump@.service should have no Conflicts=shutdown.target, and it must have Before=shutdown.target. I tried making similar changes to the corresponding .slice and .socket - but for some reason the coredump process is still getting killed. Is there any way to make systemd log the reason why a process was chosen for termination? Also, the coredump process need to complete before the the relevant partition is unmounted. Is there a way to do that? These are all systemd n00b questions. But the bigger question is about whether this is a bug in the standard unit files. Thanks Joel Holdsworth ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to stop systemd-udevd reading a device after dd
I have a device /dev/sdb1 and let's trace the block request by blktrace $ sudo blktrace -d /dev/sdb1 When I write 4KB using dd $ sudo dd if=/dev/zero of=/dev/sdb1 oflag=direct bs=4k count=1 The block trace (after blkparsed) is write request as expected 8,17 22 0.03171 5930 Q WS 2048 + 8 [dd] followed by a unexpected read from systemd-udevd 8,17 72 0.001755563 5931 Q R 2048 + 8 [systemd-udevd] My first question is what is: this read request? And I want to stop the read request because it makes it difficult to test kernel code. So the second question is: how can I stop the read request? Actually I found this behavior when I test my module https://github.com/akiradeveloper/dm-writeboost Since I need to create/remove devices during the tests, there is no choice to stop udev.service. FYI, I am using Debian 9.2 Thanks, - Akira ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
