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,
--
William
--
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
