From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753326AbdJHBIA (ORCPT ); Sat, 7 Oct 2017 21:08:00 -0400 Received: from fieldses.org ([173.255.197.46]:34458 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750981AbdJHBH6 (ORCPT ); Sat, 7 Oct 2017 21:07:58 -0400 Date: Sat, 7 Oct 2017 21:07:58 -0400 From: "J. Bruce Fields" To: Jeff Layton Cc: Jia-Ju Bai , dhowells@redhat.com, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fs/afs/flock and fs/locks: Fix possible sleep-in-atomic bugs in posix_lock_file Message-ID: <20171008010758.GA23643@fieldses.org> References: <1507370104-21751-1-git-send-email-baijiaju1990@163.com> <1507372617.26934.0.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1507372617.26934.0.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Oct 07, 2017 at 06:36:57AM -0400, Jeff Layton wrote: > On Sat, 2017-10-07 at 17:55 +0800, Jia-Ju Bai wrote: > > The kernel may sleep under a spinlock, and the function call paths are: > > afs_do_unlk (acquire the spinlock) > > posix_lock_file > > posix_lock_inode (fs/locks.c) > > locks_get_lock_context > > kmem_cache_alloc(GFP_KERNEL) --> may sleep > > > > afs_do_setlk (acquire the spinlock) > > posix_lock_file > > posix_lock_inode (fs/locks.c) > > locks_get_lock_context > > kmem_cache_alloc(GFP_KERNEL) --> may sleep > > > > To fix them, GFP_KERNEL is replaced with GFP_ATOMIC. > > These bugs are found by my static analysis tool and my code review. > > > > Signed-off-by: Jia-Ju Bai > > --- > > fs/locks.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/locks.c b/fs/locks.c > > index 1bd71c4..975cc62 100644 > > --- a/fs/locks.c > > +++ b/fs/locks.c > > @@ -222,7 +222,7 @@ struct file_lock_list_struct { > > if (likely(ctx) || type == F_UNLCK) > > goto out; > > > > - ctx = kmem_cache_alloc(flctx_cache, GFP_KERNEL); > > + ctx = kmem_cache_alloc(flctx_cache, GFP_ATOMIC); > > if (!ctx) > > goto out; > > > > NAK > > This needs to be fixed in the AFS code. It should not be calling these > functions with a spinlock held. Agreed. >>From a quick look at afs_do_setlk: am I misreading something, or is it actually trying to do an rpc call to the server while holding i_lock? I wonder if this is the fault of the BKL conversion: 72f98e72551f "locks: turn lock_flocks into a spinlock" claims "nothing depends on lock_flocks using the BKL any more, so we can do the switch over to a private spinlock." But this code, with lots of blockers, was under lock_flocks(). Does that mean nobody's tested fcntl locking over afs since that change in 2010? --b.