linux-kernel - Re: fs: WARNING in locks_free_lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ75kXaJd0NJO8T3t30+PyApVV-v8OWwzrry2xsp=KUeeWi-uQ@mail.gmail.com>
Date:	Wed, 3 Feb 2016 19:19:37 +0100
From:	William Dauchy <wdauchy@...il.com>
To:	Jeff Layton <jlayton@...chiereds.net>
Cc:	Dmitry Vyukov <dvyukov@...gle.com>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Eric Dumazet <edumazet@...gle.com>
Subject: Re: fs: WARNING in locks_free_lock_context()

Hello Jeff,

On Wed, Dec 23, 2015 at 2:54 PM, Jeff Layton <jlayton@...chiereds.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