devfs
[Top] [All Lists]

Re: stracing devfsd

To: Richard Gooch <rgooch@xxxxxxxxxxxxxxx>
Subject: Re: stracing devfsd
From: Russell Coker <russell@xxxxxxxxxxxx>
Date: Fri, 15 Feb 2002 12:20:05 +1100
Cc: Borsenkow Andrej <Andrej.Borsenkow@xxxxxxxxxxxxxx>, "'devfs mailing list'" <devfs@xxxxxxxxxxx>
In-reply-to: <200202141741.g1EHfko12085@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <000301c1b566$e241a890$21c9ca95@xxxxxxxxxxxxxx> <20020214153404.F0114C5B8@xxxxxxxxxxxxxxxxx> <200202141741.g1EHfko12085@xxxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: Russell Coker <russell@xxxxxxxxxxxx>
Sender: owner-devfs@xxxxxxxxxxx
On Fri, 15 Feb 2002 04:41, Richard Gooch wrote:
> > When you attach to it the devfsd process will think that it has been sent
> > a SIGHUP and will reload it's config (which involves simulating events
> > for all active devices).
> >
> > I think this is a bug, but haven't felt inclined to submit a patch
> > as stracing devfsd isn't something you often want to do and code
> > bloat is undesired.
>
> True, but it's actually quite cheap to fix this. Since I've already
> got a SIGHUP handler, I can set a flag there and test for it in
> do_servicing(). If I get an EINTR from sig!=SIGHUP, I'll just ignore
> it.
>
> Sound reasonable?

Yes.

> > Also while on this topic, don't run gdb on devfsd from within X.
> > The X server opens new devices if you try to change virtual consoles
> > and often at other times opens device files.  If devfsd is blocked
> > then the kernel will block all open() calls for /dev, this can
> > result in a system deadlock that can only be killed by a SAK.
>
> Ouch.

Yes.  Everyone who does any sort of debugging of system processes like devfsd 
should have SAK enabled.  Otherwise a hard reset would be required.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

<Prev in Thread] Current Thread [Next in Thread>