From: "J. Bruce Fields" <bfields@fieldses.org>
To: Linus Torvalds <torvalds@linux-foundation.org>, stable@kernel.org
Cc: linux-kernel@vger.kernel.org,
"George G. Davis" <gdavis@mvista.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel@vger.kernel.org
Subject: [PATCH, RESEND] locks: fix possible infinite loop in posix deadlock detection
Date: Tue, 30 Oct 2007 11:20:02 -0400 [thread overview]
Message-ID: <20071030152002.GA21595@fieldses.org> (raw)
In-Reply-To: <20071028173136.GA16905@fieldses.org>
From: J. Bruce Fields <bfields@citi.umich.edu>
It's currently possible to send posix_locks_deadlock() into an infinite
loop (under the BKL).
For now, fix this just by bailing out after a few iterations. We may
want to fix this in a way that better clarifies the semantics of
deadlock detection. But that will take more time, and this minimal fix
is probably adequate for any realistic scenario, and is simple enough to
be appropriate for applying to stable kernels now.
Thanks to George Davis for reporting the problem.
Cc: "George G. Davis" <gdavis@mvista.com>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
fs/locks.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
I didn't see objections to this quick fix (just to the followup that
attempts to rip out posix deadlock detection entirely), so I'm
resending with just comment modifications.
I haven't given up on a more comprehensive solution, but I think we
really need to apply some fix now.
--b.
diff --git a/fs/locks.c b/fs/locks.c
index 0127a28..8b8388e 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -696,17 +696,28 @@ EXPORT_SYMBOL(posix_test_lock);
* Note: the above assumption may not be true when handling lock requests
* from a broken NFS client. But broken NFS clients have a lot more to
* worry about than proper deadlock detection anyway... --okir
+ *
+ * However, the failure of this assumption (also possible in the case of
+ * multiple tasks sharing the same open file table) also means there's no
+ * guarantee that the loop below will terminate. As a hack, we give up
+ * after a few iterations.
*/
+
+#define MAX_DEADLK_ITERATIONS 10
+
static int posix_locks_deadlock(struct file_lock *caller_fl,
struct file_lock *block_fl)
{
struct file_lock *fl;
+ int i = 0;
next_task:
if (posix_same_owner(caller_fl, block_fl))
return 1;
list_for_each_entry(fl, &blocked_list, fl_link) {
if (posix_same_owner(fl, block_fl)) {
+ if (i++ > MAX_DEADLK_ITERATIONS)
+ return 0;
fl = fl->fl_next;
block_fl = fl;
goto next_task;
--
1.5.3.4.208.gc990
next prev parent reply other threads:[~2007-10-30 15:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071017185157.GC3785@mvista.com>
[not found] ` <20071018185759.GU3785@mvista.com>
[not found] ` <20071026170750.GC13033@fieldses.org>
[not found] ` <20071026224707.GO13033@fieldses.org>
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
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 ` J. Bruce Fields [this message]
2007-10-30 15:35 ` [PATCH, RESEND] locks: fix possible infinite loop in " Alan Cox
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=20071030152002.GA21595@fieldses.org \
--to=bfields@fieldses.org \
--cc=akpm@linux-foundation.org \
--cc=gdavis@mvista.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).