On Wed, 3 Feb 2016 19:19:37 +0100 William Dauchy <wdauchy@xxxxxxxxx> wrote: > Hello Jeff, > > On Wed, Dec 23, 2015 at 2:54 PM, Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: > > Ooh, nice catch...and just in time for Christmas. > > > > filp_close does this after the fd has been detached from the file table > > in __close_fd: > > > > if (likely(!(filp->f_mode & FMODE_PATH))) { > > dnotify_flush(filp, id); > > locks_remove_posix(filp, id); > > } > > fput(filp); > > > > ...and fcntl_setlk does this: > > > > /* > > * Attempt to detect a close/fcntl race and recover by > > * releasing the lock that was just acquired. > > */ > > /* > > * we need that spin_lock here - it prevents reordering between > > * update of i_flctx->flc_posix and check for it done in close(). > > * rcu_read_lock() wouldn't do. > > */ > > spin_lock(¤t->files->file_lock); > > f = fcheck(fd); > > spin_unlock(¤t->files->file_lock); > > if (!error && f != filp && flock.l_type != F_UNLCK) { > > flock.l_type = F_UNLCK; > > goto again; > > } > > > > ...so in principle that should keep new locks from racing onto the list > > just after we call filp_close. Hmm...I'll see if I can reproduce and > > figure out how this could happen. > > Just wondering if you had the time to figure out this warning? > > Thanks, Yes...this commit in mainline fixes it: commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 Author: Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> Date: Thu Jan 7 16:38:10 2016 -0500 locks: fix unlock when fcntl_setlk races with a close ...and the patch is applicable to all kernels currently in circulation. The original bug is very old (from 2005). -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html