Re: udev and devfs - The final word

[Andrey Borzenkov]

On Thursday 08 January 2004 20:26, Diego Calleja wrote:
> El Thu, 8 Jan 2004 23:40:16 +0800 (WST) Ian Kent <raven@xxxxxxxxxx> 
escribió:
> > Again I'm also unable to find descriptions of the 'unsolvable' races.
> >
> > I wouldn't mind knowing what they are either. Anyone?
>
> You can find tons of examples (several of them patches by Al Viro to fix
> them) by searching with google with keywords like "devfs races". The
> "should fix" list
> (http://www.kernel.org/pub/linux/kernel/people/akpm/must-fix) has this:
>

is it a gospel?

> hch: devfs: there's a fundamental lookup vs devfsd race that's only
>   fixable by introducing a lookup vs devfs deadlock.  I can't see how this
> is fixable without getting rid of the current devfsd design.  Mandrake
> seems to have a workaround for this so this is at least not triggered so
> easily, but that's not what I'd consider a fix..

oh, well ... if you selected this example ...

Mandrake workaround it mentions was my first attempt to fix this; this did not 
fix the devfs but rather fixed the user-space program that provoked this on 
boot (and that was buggy irrespectively of this problem).

Current 2.6 kernel includes my fix to deadlock condition. Current -mm includes 
one possible fix for race condition; Andrew Morton mentioned that it is 
unlikely to be accepted due to minor changes in VFS layer; I am working on 
another less intrusive fix and overall devfs cleanup.

Would you please instead of citing long obsolete paper show me real example 
and explain *why* it is not fixable. Better yet, would you take some time to 
try to provoke any of those huge races and report back your success (stack 
trace and instructions how to reproduce them are welcome :)

Thank you

-andrey

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/