On Sun, 28 Oct 2007, J. Bruce Fields wrote:
> 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.)
Don't forget that comparing file_lock->fl_owner (i.e. current->files) is
not the only way how lock ownership could be computed (there could be
specific file_lock->fl_lmops->fl_compare_owner() and all of them should
be teached this new semantics, right?).
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- [PATCH] locks: fix possible infinite loop in posix deadlock detection
- [RFC, PATCH] locks: remove posix deadlock detection
- Re: [RFC, PATCH] locks: remove posix deadlock detection
- Re: [RFC, PATCH] locks: remove posix deadlock detection
- Re: [RFC, PATCH] locks: remove posix deadlock detection
- Re: [RFC, PATCH] locks: remove posix deadlock detection
- Re: [RFC, PATCH] locks: remove posix deadlock detection
- Re: [RFC, PATCH] locks: remove posix deadlock detection
- Re: [RFC, PATCH] locks: remove posix deadlock detection
- Re: [RFC, PATCH] locks: remove posix deadlock detection
- Re: [RFC, PATCH] locks: remove posix deadlock detection
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]