Russell Coker writes:
> On Fri, 15 Feb 2002 01:50, Borsenkow Andrej wrote:
> > Debugging recent problem here I pbserved following:
> >
> > stracing devfsd for the first time using simple
> >
> > strace -p 69
> >
> > ends spitting out a screenfull of lines las one being output to stderr
> > about broken pipe.
> >
> > Stracing the same devfsd the second time puts it into endless loop
> > scanning /dev recursively and running REGISTER actions; if strace is
> > killed immediately, devfsd calms down after 18s CPU time! (as reported
> > by ps). I guess it is some bad interaction - devfsd does /dev rescan
> > *every* time it receives an event from devfs and stracing process
> > interrupts read.
> >
> > Is this rescan every time really necessary? Do I correctly understand it
> > tries to compensate for missing events? But then it could check for
> > overrun_count? Doing full rescan is very inefficient, at least here
> > where we apply permissions every time.
>
> 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?
> 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.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|