Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp4247141ybg; Mon, 8 Jun 2020 03:01:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz3cMsAaN2TSyA2tgXVof9JoM8eHam3yFSurjkNK8KHKWiI4z4EDPKstWVGVytQF3EgQu10 X-Received: by 2002:a17:906:6a1b:: with SMTP id o27mr20793373ejr.271.1591610476141; Mon, 08 Jun 2020 03:01:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591610476; cv=none; d=google.com; s=arc-20160816; b=CbO7yay0oYBuNcD00QCwn1+lhctj3x2AO85pz64OV++rpUQM1DiQm+rasU9r086RPy Ej7IU1lpFQl3QWBiu/qai7aQsg1FMs1GTlIdvbP1JXDLFbHsUufh+jAA55IL0lIaAv1r U0pwJI18UwjUHxnAfqUkknSZF0Oe9XOz4Z+SmVwsFhfJB/Va+RAeon5KcUrEsERAxzwv CK2LNiuv6i+OiEQUi1jHnYI594pf8Kb9KAqDC5PnUADJLEPnoA7InceKzW4wWJzeFC5z bDKIDktXM4WsPOXTe5AK8E8t0COqqnY1WAyI9xdCJaC8cHtJjCIkIu1pyE37O0KswTOQ Dbeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature:dkim-signature; bh=dHXvjsVk7QKN9xSmxFZliOkWW0vYwmyFZklqwFJxZx0=; b=mZ0bmgp8/16Z1cVXsIEceNGhVvJD25hnqnghk0/zjAPODiTkyayqNczKEPLp3Udyp4 Gfe7ivJuow4ObhAwGB7lav9r6tq6t0WqpoRSDBsEP/h1Yn7v2KBpHI/1UWaVC1bacpJP Ya5JlxiHDUgB7KfCfBrhBeB9WrMQWBiyJsvvV214xipBCh/5zwOGQ+FnEtVdZHB0iDtx a6/UUhK/WddFla+sEdX2aonADgkh/SNRzPnEEJwEWl7VFHthRYi1N2w9WwY5zq9RMOcL +EuNtZ4xB717+trxF1d0ak2QHzquhO0cf44JBWydDDjNfZhzpDNyXmYQwu9MaP6o8qR7 kvAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@themaw.net header.s=fm3 header.b=nbuRRuQM; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=ssUoMqNF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id df5si8675591edb.231.2020.06.08.03.00.53; Mon, 08 Jun 2020 03:01:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@themaw.net header.s=fm3 header.b=nbuRRuQM; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=ssUoMqNF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729269AbgFHJ6u (ORCPT + 99 others); Mon, 8 Jun 2020 05:58:50 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:45535 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728745AbgFHJ6t (ORCPT ); Mon, 8 Jun 2020 05:58:49 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 503415C00E7; Mon, 8 Jun 2020 05:58:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 08 Jun 2020 05:58:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; s=fm3; bh= dHXvjsVk7QKN9xSmxFZliOkWW0vYwmyFZklqwFJxZx0=; b=nbuRRuQMMotal5S8 pTkvN+cmjfx8FXtAQCeuwybBH7S6VVW0ds1kT1qKG/FvjVQYv1yuRNB3eez27HfC pFmvpUz9+o3NY2whoy/ZynFDzKKpX5CcbpGCMoUqqNpnjO5zKetMk2SDHB1T9qd9 /h3Ah3sakw4x1Jx7umnwljUFBfDSnAz1NunymMh2tg9mV8dO2pvf8PPR8WQFWxsd bp/Y2GnpF08+DJljBEOGCSwgRNxxoePPv4/zUWhCAw6sr6o6La8GDgh360TW/KW+ MQZjM/QJoTNciAnM8uXjGYhdK8CppxGSAycOS1JISb1TMuskSNPKFHoROkGpO9Db Pp/0SA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=dHXvjsVk7QKN9xSmxFZliOkWW0vYwmyFZklqwFJxZ x0=; b=ssUoMqNFeqO0sPk0K4AU8jQTyVoHyYwOSKTCca9oiggMmH3ruvzqarQG2 h0/gmIktox7m6oRVShAo3y0OPfd4rPhzHnUrqwaXupLnII4r29+jyvhafzjilfHW tRXAsy3lXN5C13RN2utfyGsdNQxIEG2/cw8rHBgIQGWWa2SJdLlV4bwlZzZARpdy aRyfdeBocNubsbdUl+2oHqMD2LQVkOwJLNFBKXHysFDNGRHsoa1vq5fanLTlobqL S5+sJV9upS05bTcN9qwF4ehETAFdkNGUkORQEiHBjZLSuY3D1waiWiMw3LwriWGX 1W8YPQbJmcOaUPlqjiHl2i5iDo6uA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehuddgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkffuhffvffgjfhgtfggggfesthejredttderjeenucfhrhhomhepkfgrnhcu mfgvnhhtuceorhgrvhgvnhesthhhvghmrgifrdhnvghtqeenucggtffrrghtthgvrhhnpe effeettedvgeduvdevfeevfeettdffudduheeuiefhueevgfevheffledugefgjeenucfk phepheekrdejrddvvddtrdegjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehrrghvvghnsehthhgvmhgrfidrnhgvth X-ME-Proxy: Received: from mickey.themaw.net (58-7-220-47.dyn.iinet.net.au [58.7.220.47]) by mail.messagingengine.com (Postfix) with ESMTPA id 8F41D328005E; Mon, 8 Jun 2020 05:58:43 -0400 (EDT) Message-ID: <6e408041ae9bedb2269cf607d7313a414c7cead3.camel@themaw.net> Subject: Re: [PATCH 1/4] kernfs: switch kernfs to use an rwsem From: Ian Kent To: Greg Kroah-Hartman Cc: Andrew Morton , l Viro , Tejun Heo , Rick Lindsley , Stephen Rothwell , David Howells , Miklos Szeredi , linux-fsdevel , Kernel Mailing List Date: Mon, 08 Jun 2020 17:58:39 +0800 In-Reply-To: <36e2d782d1aea1cfbe17f3bfee35f723f2f89c0d.camel@themaw.net> References: <159038508228.276051.14042452586133971255.stgit@mickey.themaw.net> <159038562460.276051.5267555021380171295.stgit@mickey.themaw.net> <36e2d782d1aea1cfbe17f3bfee35f723f2f89c0d.camel@themaw.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2020-06-07 at 16:40 +0800, Ian Kent wrote: > Hi Greg, > > On Mon, 2020-05-25 at 13:47 +0800, Ian Kent wrote: > > @@ -189,9 +189,9 @@ int kernfs_iop_getattr(const struct path *path, > > struct kstat *stat, > > struct inode *inode = d_inode(path->dentry); > > struct kernfs_node *kn = inode->i_private; > > > > - mutex_lock(&kernfs_mutex); > > + down_read(&kernfs_rwsem); > > kernfs_refresh_inode(kn, inode); > > - mutex_unlock(&kernfs_mutex); > > + up_read(&kernfs_rwsem); > > > > generic_fillattr(inode, stat); > > return 0; > > @@ -281,9 +281,9 @@ int kernfs_iop_permission(struct inode *inode, > > int mask) > > > > kn = inode->i_private; > > > > - mutex_lock(&kernfs_mutex); > > + down_read(&kernfs_rwsem); > > kernfs_refresh_inode(kn, inode); > > - mutex_unlock(&kernfs_mutex); > > + up_read(&kernfs_rwsem); > > > > return generic_permission(inode, mask); > > } > > I changed these from a write lock to a read lock late in the > development. > > But kernfs_refresh_inode() modifies the inode so I think I should > have taken the inode lock as well as taking the read lock. > > I'll look again but a second opinion (anyone) would be welcome. I had a look at this today and came up with a couple of patches to fix it, I don't particularly like to have to do what I did but I don't think there's any other choice. That's because the rb tree locking is under significant contention and changing this back to use the write lock will adversely affect that. But unless I can find out more about the anomalous kernel test robot result I can't do anything! Providing a job.yaml to reproduce it with the hardware specification of the lkp machine it was run on and no guidelines on what that test does and what the test needs so it can actually be reproduced isn't that useful. Ian