Messages in this thread | | | From | Andrey Borzenkov <> | Subject | Re: udev and devfs - The final word | Date | Thu, 8 Jan 2004 22:25:01 +0300 |
| |
On Thursday 08 January 2004 20:26, Diego Calleja wrote: > El Thu, 8 Jan 2004 23:40:16 +0800 (WST) Ian Kent <raven@themaw.net> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |