Re: hugetlb locking bug.

[Josh Boyer]

On Fri, Apr 15, 2011 at 2:19 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/