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>] [day] [month] [year] [list]

Message-ID: <20110822153408.GG2270@zod.bos.redhat.com>
Date:	Mon, 22 Aug 2011 11:34:08 -0400
From:	Josh Boyer <jwboyer@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	hch@...radead.org, peterz@...radead.org, davej@...hat.com,
	linux-kernel@...r.kernel.org
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?

Sorry to revive an old thread, but we've seen this reported by something
other than Dave's crazy fuzzer tool now [1].

It seems solution (a) wound up winning just because nobody chased it
further.  Is that what we want to stick with, and just close similar
reports as "false warning", or should option (c) eventually get
implemented?

josh

[1] https://bugzilla.redhat.com/show_bug.cgi?id=730998
--
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/