[PATCH] locks: pass correct "before" pointer to locks_unlink_lock in generic_add_lease

[PATCH] locks: pass correct "before" pointer to locks_unlink_lock in generic_add_lease

[Jeff Layton]

The argument to locks_unlink_lock can't be just any pointer to a
pointer. It must be a pointer to the fl_next field in the previous
lock in the list.

Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: Jeff Layton <jlayton@primarydata.com>
---
 fs/locks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/locks.c b/fs/locks.c
index cb66fb05ad4a..bb08857f90b5 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1619,7 +1619,7 @@ static int generic_add_lease(struct file *filp, long arg, struct file_lock **flp
 	smp_mb();
 	error = check_conflicting_open(dentry, arg);
 	if (error)
-		locks_unlink_lock(flp);
+		locks_unlink_lock(before);
 out:
 	if (is_deleg)
 		mutex_unlock(&inode->i_mutex);
-- 
1.9.3

Re: [PATCH] locks: pass correct "before" pointer to locks_unlink_lock in generic_add_lease

[Christoph Hellwig]

On Sat, Aug 23, 2014 at 06:36:19AM -0400, Jeff Layton wrote:
> The argument to locks_unlink_lock can't be just any pointer to a
> pointer. It must be a pointer to the fl_next field in the previous
> lock in the list.

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>

This might explain some memory corruption I saw in the lease code while
trying out a new creative (ab-)user of the lease code..

Re: [PATCH] locks: pass correct "before" pointer to locks_unlink_lock in generic_add_lease

[Jeff Layton]

On Sat, 23 Aug 2014 04:48:18 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Sat, Aug 23, 2014 at 06:36:19AM -0400, Jeff Layton wrote:
> > The argument to locks_unlink_lock can't be just any pointer to a
> > pointer. It must be a pointer to the fl_next field in the previous
> > lock in the list.
> 
> Looks good,
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> 
> This might explain some memory corruption I saw in the lease code while
> trying out a new creative (ab-)user of the lease code..
> 

Hmmm maybe. I'd certainly test it out if you have a reproducer...

That locks_unlink_lock should only get called under some very strange
(and rare) circumstances. It was added in commit 24cbe7845ea5
which describes the potential race there. I suppose it's possible but I
had always considered that race to be more in the theoretical category
than anything likely to happen under normal circumstances.

-- 
Jeff Layton <jlayton@primarydata.com>