linux-kernel - Re: hugetlb locking bug.

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: <BANLkTinSytqYA6ozOQEQ16VkRU4gFYpqvg@mail.gmail.com>
Date:	Fri, 15 Apr 2011 14:27:47 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	William Irwin <wli@...omorphy.com>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: hugetlb locking bug.

On Fri, Apr 15, 2011 at 2:19 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> (Warning: whitespace damage and TOTALLY UNTESTED)

Gaah. That won't work. Or rather, it probably may work, but while
working it will spam the logs with that

    WARN_ON(!(inode->i_state & I_NEW));

thing from unlock_new_inode.

So the sane thing to do would be apparently one of

 (a) ignore the whole thing, and just accept the false lockdep warning.

      which I'd be willing to do, but it might be hiding some real
ones, so we probably shouldn't.

 (b) just remove that WARN_ON(), and use the one-liner I suggested

 (c) extract the "set directory i_mutex key" logic into a new helper
function for the case of filesystems like hugetlbfs that don't want to
use unlock_new_inode() for one reason or another.

Personally, I don't have any really strong preferences and would
probably just go for (b) to keep the patch small and simple. Anybody?

                     Linus
--
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/