Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754706AbXJ3PU3 (ORCPT ); Tue, 30 Oct 2007 11:20:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753395AbXJ3PUS (ORCPT ); Tue, 30 Oct 2007 11:20:18 -0400 Received: from mail.fieldses.org ([66.93.2.214]:54467 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752560AbXJ3PUQ (ORCPT ); Tue, 30 Oct 2007 11:20:16 -0400 Date: Tue, 30 Oct 2007 11:20:02 -0400 To: Linus Torvalds , stable@kernel.org Cc: linux-kernel@vger.kernel.org, "George G. Davis" , Andrew Morton , linux-fsdevel@vger.kernel.org Subject: [PATCH, RESEND] locks: fix possible infinite loop in posix deadlock detection Message-ID: <20071030152002.GA21595@fieldses.org> References: <20071017185157.GC3785@mvista.com> <20071018185759.GU3785@mvista.com> <20071026170750.GC13033@fieldses.org> <20071026224707.GO13033@fieldses.org> <20071028173136.GA16905@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071028173136.GA16905@fieldses.org> User-Agent: Mutt/1.5.16 (2007-06-11) From: "J. Bruce Fields" Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2340 Lines: 69 From: J. Bruce Fields 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" Signed-off-by: J. Bruce Fields --- 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/