:: Re: [DNG] vdev status update in dae…
Pàgina inicial
Delete this message
Reply to this message
Autor: aitor
Data:  
A: dng
Assumpte: Re: [DNG] vdev status update in daedalus (Was: vdev status update in chimaera)
Hi again,

On 16/8/23 14:17, aitor wrote:
> I've found two important bugs in Jude Nelson's libudev-compat, both related to the udev monitor:
> https://github.com/jcnelson/vdev/blob/master/libudev-compat/libudev-monitor.c
> #1) The first one is in the line nº 211, where the function
> udev_monitor_new_from_filesystem( udev );
> is invoked without defining the `udev_monitor_netlink_group` as UDEV_MONITOR_UDEV, the group that
> receives the "udev" events sent out after vdev has finished its event processing, all actions have
> been processed, and needed device nodes have been created, as defined in the line nº 243:
> udev_monitor->snl_destination.nl.nl_groups = UDEV_MONITOR_UDEV;
> Bear in mind that applications should not access directly the "kernel" events before vdev has configured
> them. Only device managers like udevd, vdevd... should connect directly to them.
>
> The code in these lines should be as follows:
>
>
> else if (streq(name, "udev")) {
>
>        group = UDEV_MONITOR_UDEV;

>
>        // libudev-compat: read from an event buffer on the fs
>        return udev_monitor_new_from_filesystem( udev );

>
> }
>
>
> #2) The second bug is in the line nº 169, because this line is not considering the group UDEV_MONITOR_NONE,
> in which case name == NULL (*), resulting in a segmentation fault. So, the code should be as follows
> (the condition name != NULL is evaluated first):
> if( name && strcmp( name, "udev" ) == 0 ) {
>
>     return udev_monitor_new_from_filesystem(udev);
> }
> else {

>
>     return udev_monitor_new_from_netlink_fd(udev, name, -1);
> }
> Cheers,
> Aitor.
> [*] Look at the lines nº 204 - 206:
>   if (name == NULL) {
>       group = UDEV_MONITOR_NONE;
> }


I've improved a lot the garbage collector in the `eventfs` filesystem, mounted at "/dev/metadata/udev/events/serial".

Now, the removal of the consumed uevent files is done from the vdev helper "event-put.c":

https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/event-put.c

This binary is the responsible for propagating device events to listening processes.

There are two symlinks within each "/dev/metadata/udev/events/serial/libudev-CLIENT_PID-$slot" directory: "head" and "tail".
As soon as a new event is propagated to the queue, the already consumed event pointed by "head" is removed automatically.
It's worth to clarify that this removal is carried out as long as "head" and "tail" aren't pointing to the same file;
otherwise, both symlinks would end up pointing one another, in which case the eventfs filesystem crashes. Therefore, the
latest consumed event remains there until the propagation of the next event. This is the reason why you'll find always the
same seqnum on every `libudev-CLIENT_PID-$slot` at any time.

The problem I'm trying to solve right now is in another area related to gvfs/udisks2 and the delay of the `g_dbus_proxy_call`
when mounting/unmounting usb devices with vdev.

What the heck is delaying the replay in the message bus?

DBus is horrendous :(

Cheers,

Aitor.