public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] fs/afs/flock and fs/locks: Fix possible sleep-in-atomic bugs in posix_lock_file
@ 2017-10-07  9:55 Jia-Ju Bai
  2017-10-07 10:36 ` Jeff Layton
  0 siblings, 1 reply; 5+ messages in thread
From: Jia-Ju Bai @ 2017-10-07  9:55 UTC (permalink / raw)
  To: dhowells, viro, jlayton, bfields
  Cc: linux-fsdevel, linux-afs, linux-kernel, Jia-Ju Bai

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 <baijiaju1990@163.com>
---
 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;
 
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] fs/afs/flock and fs/locks: Fix possible sleep-in-atomic bugs in posix_lock_file
  2017-10-07  9:55 [PATCH] fs/afs/flock and fs/locks: Fix possible sleep-in-atomic bugs in posix_lock_file Jia-Ju Bai
@ 2017-10-07 10:36 ` Jeff Layton
  2017-10-08  1:07   ` J. Bruce Fields
  0 siblings, 1 reply; 5+ messages in thread
From: Jeff Layton @ 2017-10-07 10:36 UTC (permalink / raw)
  To: Jia-Ju Bai, dhowells, viro, bfields
  Cc: linux-fsdevel, linux-afs, linux-kernel

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 <baijiaju1990@163.com>
> ---
>  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.

-- 
Jeff Layton <jlayton@redhat.com>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] fs/afs/flock and fs/locks: Fix possible sleep-in-atomic bugs in posix_lock_file
  2017-10-07 10:36 ` Jeff Layton
@ 2017-10-08  1:07   ` J. Bruce Fields
  2017-10-11  9:47     ` David Howells
  0 siblings, 1 reply; 5+ messages in thread
From: J. Bruce Fields @ 2017-10-08  1:07 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Jia-Ju Bai, dhowells, viro, linux-fsdevel, linux-afs,
	linux-kernel

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 <baijiaju1990@163.com>
> > ---
> >  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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] fs/afs/flock and fs/locks: Fix possible sleep-in-atomic bugs in posix_lock_file
  2017-10-08  1:07   ` J. Bruce Fields
@ 2017-10-11  9:47     ` David Howells
  2017-10-11 13:45       ` J. Bruce Fields
  0 siblings, 1 reply; 5+ messages in thread
From: David Howells @ 2017-10-11  9:47 UTC (permalink / raw)
  To: J. Bruce Fields, Jia-Ju Bai, Jeff Layton
  Cc: dhowells, viro, linux-fsdevel, linux-afs, linux-kernel

J. Bruce Fields <bfields@fieldses.org> wrote:

> Does that mean nobody's tested fcntl locking over afs since that change in
> 2010?

Quite feasibly not.  I've been beating kAFS into shape and I'm aware of the
lock thing.  It's on the list after getting the core server rotation working
properly since that will affect a whole bunch of code, including the locking
code.

I've more or less finished the server rotation bit.  See:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=afs-2-experimental

David

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] fs/afs/flock and fs/locks: Fix possible sleep-in-atomic bugs in posix_lock_file
  2017-10-11  9:47     ` David Howells
@ 2017-10-11 13:45       ` J. Bruce Fields
  0 siblings, 0 replies; 5+ messages in thread
From: J. Bruce Fields @ 2017-10-11 13:45 UTC (permalink / raw)
  To: David Howells
  Cc: Jia-Ju Bai, Jeff Layton, viro, linux-fsdevel, linux-afs,
	linux-kernel

On Wed, Oct 11, 2017 at 10:47:43AM +0100, David Howells wrote:
> J. Bruce Fields <bfields@fieldses.org> wrote:
> 
> > Does that mean nobody's tested fcntl locking over afs since that change in
> > 2010?
> 
> Quite feasibly not.  I've been beating kAFS into shape and I'm aware of the
> lock thing.  It's on the list after getting the core server rotation working
> properly since that will affect a whole bunch of code, including the locking
> code.
> 
> I've more or less finished the server rotation bit.  See:
> 
> 	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=afs-2-experimental

Neat!

Well, pending a real fix I suppose it's probably clearest to leave the
locking code in an obviously broken state.  Might be worth a comment
though.

--b.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-10-11 13:45 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-07  9:55 [PATCH] fs/afs/flock and fs/locks: Fix possible sleep-in-atomic bugs in posix_lock_file Jia-Ju Bai
2017-10-07 10:36 ` Jeff Layton
2017-10-08  1:07   ` J. Bruce Fields
2017-10-11  9:47     ` David Howells
2017-10-11 13:45       ` J. Bruce Fields

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox