From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Tue, 16 Mar 2004 14:52:51 +0000 Subject: Re: race conditions in udevd Message-Id: <1079448770.2221.19.camel@pim> List-Id: References: <40568E9E.1080809@sympatico.ca> In-Reply-To: <40568E9E.1080809@sympatico.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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_id70&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