race conditions in udevd

race conditions in udevd

[Chris Friesen]

I just realized that we've got some gaping flaws in the udevd signal 
handler logic.

Currently the actual signal handler sets various flags.  We then wait 
for an incoming message and handle it, then check the flags to see if we 
need to do various things..

The problem is, if we get SIGALRM or SIGCHLD before we get back to 
recvmsg(), we'll wait there until the next message comes in--which could 
be quite a while.  Sorry guys, I screwed up in my original patch, and it 
took until now to see it.

The fix is straightforward.  In the init code we create a pipe.  In the 
signal handler we write a byte (based on what signal came in) to the 
pipe. We add a select() in the main loop that listens on the pipe and on 
the unix socket.  When the unix socket is readable, we run the existing 
recvmsg() code.  When the pipe is readable, we read the byte and run the 
appropriate code.

I don't have time to send a patch tonight, but will do so in the next 
few days if nobody beats me to it.

Chris



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
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: race conditions in udevd

[Kay Sievers]

On Tue, 2004-03-16 at 06:20, Chris Friesen wrote:
> I just realized that we've got some gaping flaws in the udevd signal 
> handler logic.
> 
> Currently the actual signal handler sets various flags.  We then wait 
> for an incoming message and handle it, then check the flags to see if we 
> need to do various things..
> 
> The problem is, if we get SIGALRM or SIGCHLD before we get back to 
> recvmsg(), we'll wait there until the next message comes in--which could 
> be quite a while.  Sorry guys, I screwed up in my original patch, and it 
> took until now to see it.

Seems rare, but it surely can happen. It possibly doesn't happen, cause
we usally don't have timouts, and the execution of udev needs always
longer than we need to return to the waitmsg(). Good catch, it should be
fixed.

> The fix is straightforward.  In the init code we create a pipe.  In the 
> signal handler we write a byte (based on what signal came in) to the 
> pipe. We add a select() in the main loop that listens on the pipe and on 
> the unix socket.  When the unix socket is readable, we run the existing 
> recvmsg() code.  When the pipe is readable, we read the byte and run the 
> appropriate code.

A control socket seems to be the best fix for this. A longjmp() from the
signal handler below the handle_msg() is too ugly, right :)

> I don't have time to send a patch tonight, but will do so in the next 
> few days if nobody beats me to it.

Ohh, I expect that nobody want's to beat you :)
I recently posted a patch for udevsend to return with the exit code of
the real udev, based on your "ack msg" patch. So the script which calls
udevsend can decide if it wants to retry it instead of doing it in
udevsend itself.
I want to have this in, cause udevsend should better wait until the
nodes are created. If nobody objects, I think we should do the fix and
the "wait for ack msg" together.

thanks,
Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
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