[REPOST] uevent leak

[REPOST] uevent leak

[Alexander E. Patrakov]

I have already reported the case where some uevents that happened after the 
"official" waiting loop exits:

http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m\x113724427424947&w=2

At that time, only USB related uevents were reported and thus the report was 
ignored as unimportant. However, we have the case when other (more 
important) uevents leak, such as those for ttys. Details are below.

It seems that this bug is easier to trigger on fast machines with very 
simple rules, such as 
http://downloads.linuxfromscratch.org/udev-config-6.rules (one single file 
contains all rules). To see the problem, one must compile a simple event 
recorder. A C program is used instead of the shell script in order to reduce 
the change in timing:

/* Simple event recorder */
/* gcc -o /lib/udev/bug this_file.c */
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <argz.h>

int main(int argc, char * argv[])
{
         char * envz;
         size_t len;
         int bug;
         bug = open("/dev/bug", O_WRONLY | O_APPEND);
         if (bug = -1)
                 return 0;
         setenv("_SEPARATOR", "--------------------------------------", 1);
         argz_create(environ, &envz, &len);
         argz_stringify(envz, len, '\n');
         envz[len-1]='\n';
         write(bug, envz, len);
         close(bug);
         free(envz);
         return 0;
}

This program appends the uevent environment to the /dev/bug file if it 
exists, and does nothing otherwise. Add a single rule to 90-debug.rules to 
run this program for every "add" uevent:

ACTION="add", RUN+="bug"

The important part of the failing initscript is:

================
         # Start the udev daemon to continually watch for, and act on, 
   uevents
         /sbin/udevd --daemon

         # Now traverse /sys in order to "coldplug" devices that have
         # already been discovered
         mkdir -p /dev/.udev/queue
         /sbin/udevtrigger  # or the old bash "for" loop with echo "add"

         # until we know how to do better, just wait for _all_ events to finish
         loop00
         while test -d /dev/.udev/queue; do
             sleep 0.1
             test "$loop" -gt 0 || break
             loop=$(($loop - 1))
         done
         >/dev/bug   # enable the logger above
         test "$loop" -gt 0
         evaluate_retval  # prints "OK" or "FAILED"
         sleep 6     # if the logger logs anything, it is a bug
         if test -s /dev/bug; then
             mv /dev/bug /dev/bugreport
             echo "Please paste the /dev/bugreport file to"
             echo "http://wiki.linuxfromscratch.org/lfs/ticket/1720"
             # and we actually have some pasted bugreports
             sleep 10
         else
             rm -f /dev/bug
         fi
================

The /dev/bugreport file is generated, as can be seen from the script, if 
there are any uevents within 6 seconds after the waiting loop exits.

The theory (well, not theory, just an unconfirmed guess) behind this 
bugreport, so far, is that udevd responds to uevents very quickly, faster 
than the kernel can deliver them from the netlink socket buffer. This leads 
to some moments when the queue is actually empty, and the loop exits 
prematurely.

The workaround is to exit the loop not when the queue disappears, but when 
it doesn't reappear for a sufficiently long time (6 seconds in the example 
below, but 1 second is sufficient for the bugreport to be reduced to USB 
devices only):

         loop00
         confirm=0
         while true ; do
             sleep 0.1
             test -d /dev/.udev/queue && confirm=0 || confirm=$(( $confirm + 
1 ))
             loop=$(( $loop - 1 ))
             test $loop -gt 0 || break
             test $confirm -lt 60 || break
         done
         test "$loop" -gt 0
         evaluate_retval  # prints "OK" or "FAILED"

-- 
Alexander E. Patrakov


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [REPOST] uevent leak

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

On Sun, 26 Mar 2006 10:21:37 +0600 Alexander E. Patrakov wrote:

> The theory (well, not theory, just an unconfirmed guess) behind this 
> bugreport, so far, is that udevd responds to uevents very quickly, faster 
> than the kernel can deliver them from the netlink socket buffer. This leads 
> to some moments when the queue is actually empty, and the loop exits 
> prematurely.

Yes, the check for empty udev queue seems to be unreliable.

One way to make this reliable could be to trigger some kind of "sync"
event after all other events from udevtrigger, catch that event in an
udev rule and do something to notify the script (e.g., remove some
file).  There is a problem, however: udevd can process events out of
order if their DEVPATH values do not overlap (see running_with_devpath()
in udevd.c), so the device for that event has to be really special.

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [REPOST] uevent leak

[Jürg Billeter]

On Son, 2006-03-26 at 23:46 +0400, Sergey Vlasov wrote:
> On Sun, 26 Mar 2006 10:21:37 +0600 Alexander E. Patrakov wrote:
> 
> > The theory (well, not theory, just an unconfirmed guess) behind this 
> > bugreport, so far, is that udevd responds to uevents very quickly, faster 
> > than the kernel can deliver them from the netlink socket buffer. This leads 
> > to some moments when the queue is actually empty, and the loop exits 
> > prematurely.
> 
> Yes, the check for empty udev queue seems to be unreliable.
> 
> One way to make this reliable could be to trigger some kind of "sync"
> event after all other events from udevtrigger, catch that event in an
> udev rule and do something to notify the script (e.g., remove some
> file).  There is a problem, however: udevd can process events out of
> order if their DEVPATH values do not overlap (see running_with_devpath()
> in udevd.c), so the device for that event has to be really special.

Another problem is that RUN rules may trigger secondary events which
very probably get executed after that special event.
If /sys/kernel/uevent_seqnum is always up-to-date, it might be possible
to compare that file with the seqnum last processed by udev, not sure,
if this works, though.

Jürg



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel