From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C120C4360F for ; Thu, 14 Mar 2019 23:09:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 39B0921874 for ; Thu, 14 Mar 2019 23:09:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="gZVronll" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728083AbfCNXJG (ORCPT ); Thu, 14 Mar 2019 19:09:06 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:38162 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727489AbfCNXJG (ORCPT ); Thu, 14 Mar 2019 19:09:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ts5oSoRBMToILEVevXhcTYaOZ60FFJYf000cZyqO3c4=; b=gZVronll/14pb8uU4blO+rrmA K8FLp0qkXlv5Hs+Ts22veIjMMETfmreMQG5b3JNX92lC+pUKQolh1YQbGhcCKl+/36XrCAJ2U7Ism Af3RJJaMEcH3FbuQvDsuDkfC2eoUrbM3pPjHIuAnCH4osLtr/Ooiaec66Hfs9CQH9iJarPNkT8ZDU rZc3LOn17mJYLqKZewpzzsZhjWJobaBFkXustUKBYPtCSYemvet9XCPY7yI4DbcS64AxCNpQAHyS9 maKyULDi5c/YyJCSHX+QQ1ev8KcqoCGPnyuCpUWkwi+UC+S2pOPX5uJyLArw8fsMn6gaT1vKmZGtU WGpT/PDTg==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1h4ZTF-000082-8M; Thu, 14 Mar 2019 23:09:05 +0000 Date: Thu, 14 Mar 2019 16:09:05 -0700 From: Matthew Wilcox To: "Tobin C. Harding" Cc: linux-fsdevel@vger.kernel.org Subject: Re: dcache locking question Message-ID: <20190314230904.GO19508@bombadil.infradead.org> References: <20190314225632.GB15813@eros.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190314225632.GB15813@eros.localdomain> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Mar 15, 2019 at 09:56:32AM +1100, Tobin C. Harding wrote: > Could someone please explain to me how the locking order commented at > the top of the file is not violated in the following: > > >From top of fs/dcache.c > > * If there is an ancestor relationship: > * dentry->d_parent->...->d_parent->d_lock > * ... > * dentry->d_parent->d_lock > * dentry->d_lock > > > dentry_kill() appears to require caller to hold the dentry->d_lock yet > it locks the parent with spin_trylock(&parent->d_lock), if this > fails it calls __lock_parent() which releases the dentry->d_lock before > locking the parent and re-acquiring [1] the dentry->d_lock . Is this not > locking in two different orders? What you're describing here is how we work around having to lock in the wrong order. There are "a few" places in the kernel where we do this. Calling spin_trylock() won't deadlock -- it'll just return failure. At that point, we drop the child, spin waiting for the parent, then lock the child. > [1] I do not fully understand the spin_lock_nested() macro. It describes to lockdep that, while it looks like we're acquiring a lock that we already own, there's actually a hierarchy of locks that are in the same lock class; we're attempting to acquire a lock in "subclass N". N is allowed to be between 0-7, inclusive.