On Sun, Oct 28, 2007 at 11:38:26PM +0000, Alan Cox wrote: > > > The spec and SYSV certainly ignore threading in this situation and you > > > know that perfectly well (or did in 2004) > > > > The discussion petered out (or that mailing list archive lost articles > > from the thread) without any kind of resolution, or indeed interest. > > I think the resolution was that the EDEADLK stayed. > > > What is your suggestion for handling this problem? As it is now, the > > kernel 'detects' deadlock where there is none, which doesn't seem > > allowed by SuSv3 either > > Re-read the spec. The EDEADLK doesn't account for threads, only processes. Do you have in mind a way to take advantage of that distinction? The practical requirement I see here is that our deadlock detection should never give false positives. If we return EDEADLK to applications with locking schemes that don't actually deadlock, then we're telling application designers that avoiding deadlock in itself isn't sufficient--they also have to know our particular deadlock detection algorithm, so as to avoid giving even the appearance of deadlock. And if posix file locks are to be useful to threaded applications, then we have to preserve the same no-false-positives requirement for them as well. But, OK, if we can identify unshared current->files at the time we put a task to sleep, then a slight modification of our current algorithm might be sufficient to detect any deadlock that involves purely posix file locks and processes. And we can tell people that avoiding deadlock is their problem as soon as any task with a shared current->files is involved. (Ditto, I assume, if nfsd/lockd acquires a lock.) --b. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
