lkml.org 
[lkml]   [2016]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: fs: WARNING in locks_free_lock_context()
Hello Jeff,

On Wed, Dec 23, 2015 at 2:54 PM, Jeff Layton <jlayton@poochiereds.net> 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(&current->files->file_lock);
> f = fcheck(fd);
> spin_unlock(&current->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

\
 
 \ /
  Last update: 2016-02-03 19:41    [W:0.199 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site