On Mon, Oct 29, 2007 at 08:06:04AM +0000, Alan Cox wrote: > On Sun, 28 Oct 2007 13:43:21 -0400 > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > From: J. Bruce Fields <bfields@xxxxxxxxxxxxxx> > > > > We currently attempt to return -EDEALK to blocking fcntl() file locking > > requests that would create a cycle in the graph of tasks waiting on > > locks. > > > > This is inefficient: in the general case it requires us determining > > whether we're adding a cycle to an arbitrary directed acyclic graph. > > And this calculation has to be performed while holding a lock (currently > > the BKL) that prevents that graph from changing. > > > > It has historically been a source of bugs; most recently it was noticed > > that it could loop indefinitely while holding the BKL. > > > > It seems unlikely to be useful to applications: > > - The difficulty of implementation has kept standards from > > requiring it. (E.g. SUSv3 : "Since implementation of full > > deadlock detection is not always feasible, the [EDEADLK] error > > was made optional.") So portable applications may not be able to > > depend on it. > > - It only detects deadlocks that involve nothing but local posix > > file locks; deadlocks involving network filesystems or other kinds > > of locks or resources are missed. > > > > It therefore seems best to remove deadlock detection. > > > > Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxxxxxx> > > > NAK. This is an ABI change OK, fair enough. > and one that was rejected before when this was last discussed in > detail. That previous discussion (http://marc.info/?t=108652857400003&r=1&w=2) read the spec wrong and--now that I reread it--failed to address the original bug report. In fact it looks to me like the actual bug reported: http://bugzilla.kernel.org/show_bug.cgi?id=2829 was probably a minor variant of the one which George Davis stumbled on again here. That's a little depressing. > Moving it out of BKL makes a ton of sense, That would at least reduce the impact of bugs here, yeah. It would be great to figure out how to start getting locks.c and lockd out from under the BKL, but I don't personally have the time now. (And I believe there's been a failed attempt or two so it's not completely easy.) > even adding a "don't check" flag makes a lot of sense. That's an idea I'll keep in mind, though I'm not convinced it'll help much (or that applications would actually use it). > The failure case for removing this feature is obscure and hard to debug > application hangs for the afflicted programs - not nice for users at all. Yeah. I'd still be curious for any data about applications that actually rely on posix deadlock detection, though. --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
