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:4.195 / U:0.236 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site