Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp583182rwb; Thu, 27 Jul 2023 18:21:55 -0700 (PDT) X-Google-Smtp-Source: APBJJlHAt070AZwn/1ImL9gduX6Gifa9hBvKa10dUohbl2JmU6VjszjacXIafUOGXymWdOmHz61e X-Received: by 2002:a17:90a:ead0:b0:263:f39:496d with SMTP id ev16-20020a17090aead000b002630f39496dmr241828pjb.44.1690507315668; Thu, 27 Jul 2023 18:21:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690507315; cv=none; d=google.com; s=arc-20160816; b=fkaMpskIMi9K+7EamBpkt45FDj7CRpsT2wSbxwDl3CbIqG4IHhYaN9ab7NFu8crA9+ WrjzJDND3U0JhWpPdlR3Z8SFcaxsM6BTYpVLvXDx6bvfPLX6iy+60rwgNpuhXIXWSHmF 8+/HKu11jdEBUY4jIFj4yXUynCG5m3uKQIIQnzDll14P0lM3Tqbz4bVI6HwKmzr6+hZG VPY+kkjbTJDQFdqOiWv1416R2wM7yTdSBMXEWrPB3i25KXEcsfCVPO6j3UK+TO0vl4tp pc2ceRuBWAT6rl+G2286nlK8Hv1Fyu5sxJ1gD2S7WYA4sigFKDn6DgV2+TGOdm1udrmO Spfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:feedback-id:dkim-signature:dkim-signature; bh=YDZ5wrTMEoKyUez3DWoQJzeqieGk0xzOSK5lvx+th/c=; fh=pe6mjuj1k0FutDz3Imt+fxrEghRVZ1IQFc3RF5arTSQ=; b=tTEA9WVYCbrEbQcnQdQHnufTnsxssiHm93hnLWaMsX9zGFLrXRQEF0lcqkhmwTMITq g45Xwoig31x7O2i+ZN1RV2PCtsFdLZJr/WcQsDk0XkpaqdF1sdfrPdy57SXXFQNT6M35 M05hj4zw45wxUIIe7uRF86HoZyx/WGqIyf+igFuaBH5ovVOjcNtBkMOErP/oULSiZBRA yyw0IKQVatTvIn3INwhG7JfxCp8tvhmHPbyao51N6Mai2SoBPDQrc9cvq5xARQiI4F3c sO5hLG676VklnvP9bsUlyc2piLzUjLLtEOv5MSXkmbz71YQscrRCesAbAtRKbjn689I1 hojg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@themaw.net header.s=fm2 header.b=GSezMDM4; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=d1GPFATM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i9-20020a17090acf8900b00267d1517c70si3705814pju.53.2023.07.27.18.21.41; Thu, 27 Jul 2023 18:21:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@themaw.net header.s=fm2 header.b=GSezMDM4; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=d1GPFATM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231254AbjG1AA6 (ORCPT + 99 others); Thu, 27 Jul 2023 20:00:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230105AbjG1AAx (ORCPT ); Thu, 27 Jul 2023 20:00:53 -0400 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 787401BF4; Thu, 27 Jul 2023 17:00:52 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E07585C0062; Thu, 27 Jul 2023 20:00:51 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 27 Jul 2023 20:00:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1690502451; x=1690588851; bh=YDZ5wrTMEoKyUez3DWoQJzeqieGk0xzOSK5 lvx+th/c=; b=GSezMDM4tpgPyc3/2yAMYOeovTwPFQ7/URTDGh0jIsW5loyQ8qE GWsxWPIYJ/CIyon1lVUG5EU3lia2Czq/9Zb19hvLYVenjRQjAugKF/nJqYSyVAfE x38Rr5IuEDN2YtRkKhxQanSzwTr45+dIsFGwS//gled2QNrRR5S4qYJKXQebRF3E ukO0jYpJ+nRyUBJD7MLQ1+SwoZvLZDImcXOEZa/1XsjrgfmJk4NTn4r0TW0ljKmU VDFdfAjvTpWldaoKrP24Lk/va/OHwpNzbZ6+zazYaEOGPPt71MqGscVnMeBSJQHw dItriuSzXfG/XHMD0ay65yIn0NCl4SPvnbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1690502451; x=1690588851; bh=YDZ5wrTMEoKyUez3DWoQJzeqieGk0xzOSK5 lvx+th/c=; b=d1GPFATMb4cJnbcHH1SK+5kFcDnmExRbGoPhuS9HZfU8+pSVoXT 8nsEUUrlbnCB5yRGck7I29Naxwp8cFg42ETug21XERIVGWedYr6+aJTr+DgpZccg /f743TBiGg1ZeePRsvgJ+Ud+o1wLo0tNTFs8sZyIDAuCzEb6/+4ape+8s4VIyKuF XEtz0gvEcDczaGa+IJaiciMnjDBPYx1i5+Ccv+lu+gCu0sxGb9Yw+3xp8UUPe2zi lf1/K6wjFkZurpUmobgyVgSvo6KbiTtXL82nATLQ++cUY3T1VpzPPABhDu+mvI9b kQeCKNpQ9m1XEn+o9tnCJJnpX1ncefl5QCg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrieehgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepkfgrnhcu mfgvnhhtuceorhgrvhgvnhesthhhvghmrgifrdhnvghtqeenucggtffrrghtthgvrhhnpe egvdetvedvfeeivdeuueejgeetvdehlefhheethfekgfejueffgeeugfekudfhjeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrrghvvghnse hthhgvmhgrfidrnhgvth X-ME-Proxy: Feedback-ID: i31e841b0:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Jul 2023 20:00:44 -0400 (EDT) Message-ID: <996e11bf-5f22-3ab7-2951-92109649195d@themaw.net> Date: Fri, 28 Jul 2023 08:00:39 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH 1/2] kernfs: dont take i_lock on inode attr read To: Imran Khan , Anders Roxell Cc: Arnd Bergmann , Tejun Heo , Greg Kroah-Hartman , Minchan Kim , Eric Sandeen , Alexander Viro , Rick Lindsley , David Howells , Miklos Szeredi , Carlos Maiolino , linux-fsdevel , Kernel Mailing List , elver@google.com References: <166606025456.13363.3829702374064563472.stgit@donald.themaw.net> <166606036215.13363.1288735296954908554.stgit@donald.themaw.net> <20221221133428.GE69385@mutt> <7815c8da-7d5f-c2c5-9dfd-7a77ac37c7f7@themaw.net> <9e35cf66-79ef-1f13-dc6b-b013c73a9fc6@themaw.net> <20230718190009.GC411@mutt> <76fcd1fe-b5f5-dd6b-c74d-30c2300f3963@themaw.net> <15eddad0-e73b-2686-b5ba-eaacc57b8947@themaw.net> <3505769d-9e7a-e76d-3aa7-286d689345b6@oracle.com> Content-Language: en-US From: Ian Kent In-Reply-To: <3505769d-9e7a-e76d-3aa7-286d689345b6@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/7/23 12:30, Imran Khan wrote: > Hello Ian, > Sorry for late reply. I was about to reply this week. > > On 27/7/2023 10:38 am, Ian Kent wrote: >> On 20/7/23 10:03, Ian Kent wrote: >>> On Wed, 2023-07-19 at 12:23 +0800, Ian Kent wrote: > [...] >>> I do see a problem with recent changes. >>> >>> I'll send this off to Greg after I've done some testing (primarily just >>> compile and function). >>> >>> Here's a patch which describes what I found. >>> >>> Comments are, of course, welcome, ;) >> Anders I was hoping you would check if/what lockdep trace >> >> you get with this patch. >> >> >> Imran, I was hoping you would comment on my change as it >> >> relates to the kernfs_iattr_rwsem changes. >> >> >> Ian >> >>> kernfs: fix missing kernfs_iattr_rwsem locking >>> >>> From: Ian Kent >>> >>> When the kernfs_iattr_rwsem was introduced a case was missed. >>> >>> The update of the kernfs directory node child count was also protected >>> by the kernfs_rwsem and needs to be included in the change so that the >>> child count (and so the inode n_link attribute) does not change while >>> holding the rwsem for read. >>> > kernfs direcytory node's child count changes in kernfs_(un)link_sibling and > these are getting invoked while adding (kernfs_add_one), > removing(__kernfs_remove) or moving (kernfs_rename_ns)a node. Each of these > operations proceed under kernfs_rwsem and I see each invocation of > kernfs_link/unlink_sibling during the above mentioned operations is happening > under kernfs_rwsem. > So the child count should still be protected by kernfs_rwsem and we should not > need to acquire kernfs_iattr_rwsem in kernfs_link/unlink_sibling. Yes, that's exactly what I intended (assuming you mean write lock in those cases) when I did it so now I wonder what I saw that lead to my patch, I'll need to look again ... > > Kindly let me know your thoughts. I would still like to see new lockdep traces > with this change. Indeed, I hope Anders can find time to get the trace. Ian > > Thanks, > Imran > >>> Fixes: 9caf696142 (kernfs: Introduce separate rwsem to protect inode >>> attributes) >>> >>> Signed-off-by: Ian Kent >>> Cc: Anders Roxell >>> Cc: Imran Khan >>> Cc: Arnd Bergmann >>> Cc: Minchan Kim >>> Cc: Eric Sandeen >>> --- >>>   fs/kernfs/dir.c |    4 ++++ >>>   1 file changed, 4 insertions(+) >>> >>> diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c >>> index 45b6919903e6..6e84bb69602e 100644 >>> --- a/fs/kernfs/dir.c >>> +++ b/fs/kernfs/dir.c >>> @@ -383,9 +383,11 @@ static int kernfs_link_sibling(struct kernfs_node >>> *kn) >>>       rb_insert_color(&kn->rb, &kn->parent->dir.children); >>>         /* successfully added, account subdir number */ >>> +    down_write(&kernfs_root(kn)->kernfs_iattr_rwsem); >>>       if (kernfs_type(kn) == KERNFS_DIR) >>>           kn->parent->dir.subdirs++; >>>       kernfs_inc_rev(kn->parent); >>> +    up_write(&kernfs_root(kn)->kernfs_iattr_rwsem); >>>         return 0; >>>   } >>> @@ -408,9 +410,11 @@ static bool kernfs_unlink_sibling(struct >>> kernfs_node *kn) >>>       if (RB_EMPTY_NODE(&kn->rb)) >>>           return false; >>>   +    down_write(&kernfs_root(kn)->kernfs_iattr_rwsem); >>>       if (kernfs_type(kn) == KERNFS_DIR) >>>           kn->parent->dir.subdirs--; >>>       kernfs_inc_rev(kn->parent); >>> +    up_write(&kernfs_root(kn)->kernfs_iattr_rwsem); >>>         rb_erase(&kn->rb, &kn->parent->dir.children); >>>       RB_CLEAR_NODE(&kn->rb); >>>