linux-kernel - Re: fs: locks: WARNING: CPU: 16 PID: 4296 at fs/locks.c:236 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150116094028.4ffd675f@tlielax.poochiereds.net>
Date:	Fri, 16 Jan 2015 09:40:28 -0500
From:	Jeff Layton <jeff.layton@...marydata.com>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	Jeff Layton <jeff.layton@...marydata.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: fs: locks: WARNING: CPU: 16 PID: 4296 at fs/locks.c:236
 locks_free_lock_context+0x10d/0x240()

On Fri, 16 Jan 2015 09:31:23 -0500
Sasha Levin <sasha.levin@...cle.com> wrote:

> On 01/15/2015 03:22 PM, Jeff Layton wrote:
> > Ok, I tried to reproduce it with that and several variations but it
> > still doesn't seem to do it for me. Can you try the latest linux-next
> > tree and see if it's still reproducible there?
> 
> It's still not in in today's -next, could you send me a patch for testing
> instead?
> 

Seems to be there for me:

----------------------[snip]-----------------------
/*
 * This function is called on the last close of an open file.
 */
void locks_remove_file(struct file *filp)
{
        /* ensure that we see any assignment of i_flctx */
        smp_rmb();

        /* remove any OFD locks */
        locks_remove_posix(filp, filp);
----------------------[snip]-----------------------

That's actually the right place to put the barrier, I think. We just
need to ensure that this function sees any assignment to i_flctx that
occurred before this point. By the time we're here, we shouldn't be
getting any new locks that matter to this close since the fcheck call
should fail on any new requests.

If that works, then I'll probably make some other changes to the set
and re-post it next week.

Many thanks for helping me test this!
-- 
Jeff Layton <jlayton@...marydata.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/