Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1325805

Re: fs: WARNING in locks_free_lock_context()

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: fs: WARNING in locks_free_lock_context() William Dauchy <wdauchy@gmail.com> - 2016-02-03 19:30 +0100
  Re: fs: WARNING in locks_free_lock_context() Jeff Layton <jlayton@poochiereds.net> - 2016-02-03 19:30 +0100
    Re: fs: WARNING in locks_free_lock_context() William Dauchy <wdauchy@gmail.com> - 2016-02-03 19:30 +0100

csiph-web