mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Matthew Wilcox <matthew@wil.cx>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	"George G. Davis" <gdavis@mvista.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [RFC, PATCH] locks: remove posix deadlock detection
Date: Sun, 28 Oct 2007 18:40:52 +0000	[thread overview]
Message-ID: <20071028184052.49abd092@the-village.bc.nu> (raw)
In-Reply-To: <20071028182732.GK27248@parisc-linux.org>

On Sun, 28 Oct 2007 12:27:32 -0600
Matthew Wilcox <matthew@wil.cx> wrote:

> On Sun, Oct 28, 2007 at 01:43:21PM -0400, J. Bruce Fields wrote:
> > 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 can also return -EDEADLK spuriously.  So yeah, just kill it.

NAK. This is an ABI change. It was also comprehensively rejected before
because

- EDEADLK behaviour is ABI
- EDEADLK behaviour is required by SuSv3
- We have no idea what applications may rely on this behaviour.

and also SuSv3 is required by LSB

See the thread
	http://osdir.com/ml/file-systems/2004-06/msg00017.html

so we need to fix the bugs - the lock usage and the looping. At that
point it merely becomes a performance concern to those who use it, which
is the proper behaviour. If you want a faster non-checking one use
flock(), or add another flag that is a Linux "don't check for deadlock"

Alan

  reply	other threads:[~2007-10-28 18:39 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-17 18:51 [RFC][PATCH] Fix hang in posix_locks_deadlock() George G. Davis
2007-10-17 23:41 ` George G. Davis
2007-10-18 18:57 ` George G. Davis
2007-10-26 17:07   ` J. Bruce Fields
2007-10-26 22:47     ` J. Bruce Fields
2007-10-28 17:31       ` [PATCH] locks: fix possible infinite loop in posix deadlock detection J. Bruce Fields
2007-10-28 17:43         ` [RFC, PATCH] locks: remove " J. Bruce Fields
2007-10-28 18:27           ` Matthew Wilcox
2007-10-28 18:40             ` Alan Cox [this message]
2007-10-28 20:11               ` Matthew Wilcox
2007-10-28 21:38                 ` Alan Cox
2007-10-28 21:45                   ` Jiri Kosina
2007-10-28 23:38                   ` Matthew Wilcox
2007-10-28 23:44                     ` Alan Cox
2007-10-28 21:50                 ` Trond Myklebust
2007-10-28 22:41                   ` Matthew Wilcox
2007-10-28 22:48                     ` Alan Cox
2007-10-28 22:55                       ` Matthew Wilcox
2007-10-28 23:38                         ` Alan Cox
2007-10-29  2:29                           ` J. Bruce Fields
2007-10-29  8:08                             ` Alan Cox
2007-10-29  9:15                             ` Jiri Kosina
2007-10-30 15:35                               ` J. Bruce Fields
2007-10-28 22:55                     ` Jiri Kosina
2007-10-28 23:31                       ` Matthew Wilcox
2007-10-29  9:11                         ` Jiri Kosina
2007-10-29  2:10                     ` J. Bruce Fields
2007-10-29  3:26                     ` Trond Myklebust
2007-10-29  1:13               ` J. Bruce Fields
2007-10-29  8:06           ` Alan Cox
2007-10-30 15:51             ` J. Bruce Fields
2007-10-30 15:20         ` [PATCH, RESEND] locks: fix possible infinite loop in " J. Bruce Fields
2007-10-30 15:35           ` Alan Cox
2007-10-28 17:47       ` [RFC][PATCH] Fix hang in posix_locks_deadlock() J. Bruce Fields
2007-11-02 15:05     ` George G. Davis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071028184052.49abd092@the-village.bc.nu \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=bfields@fieldses.org \
    --cc=gdavis@mvista.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®