Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757243Ab1DOVaX (ORCPT ); Fri, 15 Apr 2011 17:30:23 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:60041 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757064Ab1DOVaW (ORCPT ); Fri, 15 Apr 2011 17:30:22 -0400 MIME-Version: 1.0 In-Reply-To: References: <20110415201652.GA5131@redhat.com> <20110415205712.GA13049@infradead.org> <1302901766.2035.39.camel@laptop> From: Linus Torvalds Date: Fri, 15 Apr 2011 14:27:47 -0700 Message-ID: Subject: Re: hugetlb locking bug. To: Peter Zijlstra Cc: Christoph Hellwig , Dave Jones , Linux Kernel , William Irwin , Ingo Molnar Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1212 Lines: 34 On Fri, Apr 15, 2011 at 2:19 PM, Linus Torvalds 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/