Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751975Ab2BQGrp (ORCPT ); Fri, 17 Feb 2012 01:47:45 -0500 Received: from mail04-md.ns.itscom.net ([175.177.155.114]:56519 "EHLO mail04-md.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751512Ab2BQGro (ORCPT ); Fri, 17 Feb 2012 01:47:44 -0500 From: "J. R. Okajima" Subject: Re: hugetlbfs lockdep spew revisited. To: Al Viro Cc: Tyler Hicks , Josh Boyer , Dave Jones , Linux Kernel In-Reply-To: <20120217004922.GN23916@ZenIV.linux.org.uk> References: <20120217000856.GA13112@redhat.com> <20120217001634.GH23550@zod.bos.redhat.com> <20120217003848.GB20071@boyd> <20120217004922.GN23916@ZenIV.linux.org.uk> Date: Fri, 17 Feb 2012 15:47:41 +0900 Message-ID: <12592.1329461261@jrobl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 872 Lines: 24 Al Viro: > Sigh... That patch is correct, but it has nothing to do with the locking > order violation that really *is* there. The only benefit would be to > get rid of the "deadlock is not possible" nonsense, since you would see > read/write vs. mmap instead of readdir vs. mmap in the traces. Locking ::: How do you think about this patch? Re: [RFC 0/2] locking order of mm->mmap_sem and various FS http://marc.info/?l=linux-kernel&m=132124846728745&w=2 Ah, I found mutex_destroy() call in hugetlbfs_destroy_inode() should be removed. If you think this approach is good, then I'd post a revised patch. J. R. Okajima -- 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/