linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: race conditions in udevd
Date: Tue, 16 Mar 2004 14:52:51 +0000	[thread overview]
Message-ID: <1079448770.2221.19.camel@pim> (raw)
In-Reply-To: <40568E9E.1080809@sympatico.ca>

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

      reply	other threads:[~2004-03-16 14:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-16  5:20 race conditions in udevd Chris Friesen
2004-03-16 14:52 ` Kay Sievers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1079448770.2221.19.camel@pim \
    --to=kay.sievers@vrfy.org \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).