From nobody Tue Apr 7 16:17:36 2026 Received: from flow-b5-smtp.messagingengine.com (flow-b5-smtp.messagingengine.com [202.12.124.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A04D7275B18; Fri, 13 Mar 2026 00:43:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.140 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773362613; cv=none; b=M4XTur3tottSfeLtpJV1SjJDBLyfoHVdfAbb24sRUtOmuhabn+owWNxhENHIeBA6DhRpWwW0SOojVoh2M89aQIzmYllvyNPCyhMl4s22C2wiGBHaA2LPql4ESwxtyMgKYXYzoDdezAIB2xZ7BO2/yF+rC4t16uCUeXvwQaUDvB0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773362613; c=relaxed/simple; bh=H53rHtuIKkJV2K/5nZ4HjRth0TKSPLKyiXBZ0GjJYsI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=B1NnYPP6DexDEQQ78g5W3Yvs3HD69c5MXHh97N1+Q+KZYVer+d2ThAlUM3ep6/1yi3UQllt4XJRmFR0y4mURSUz6KLrZ+/KP7zJzB15b6HJHqgfJ0kjRi8ayYWdqi1Puajud0gix9iYLaQtfPdkYrtSGDD6+5C+oU1SpG8yntrE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net; spf=pass smtp.mailfrom=ownmail.net; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b=WX7c3DKP; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=TKoMfHHk; arc=none smtp.client-ip=202.12.124.140 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ownmail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ownmail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ownmail.net header.i=@ownmail.net header.b="WX7c3DKP"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="TKoMfHHk" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailflow.stl.internal (Postfix) with ESMTP id DDA261301B24; Thu, 12 Mar 2026 20:43:28 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Thu, 12 Mar 2026 20:43:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ownmail.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to; s=fm1; t=1773362608; x=1773369808; bh=8aHffWYVzxlbvh037JlVhR8ERE/IxGWBZRv5qHj7bJk=; b= WX7c3DKPx+tVVhFVjUW8//0VWvS4las6XMedU6aTYpr242woaOIcqjdZZVJ4yVnC P88WJrijdCqh71ZQjfLl+xhjGoQMg/F8wZ7GNOHUOS+3PK7l64Z9RcJfHzu3EJx+ 9kiGTP3jc4KeZly7RqBISMFoHeUWIhyiLSOgatDGNqU+ils1tsCxI9p7zB3O39nq cROINYPyREvgD1SKVCYqH32NWAcedBFxE+Wuyiva088VcFlPPudW1EKncv3fsuaA BShtlQMTfihkHb/wYJyVBjIX251wX3ueq3TmnmoWiRxo/NGW66kYiWp2sylnh++s bFkFlicATpGbeU9QOA95Jw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1773362608; x=1773369808; bh=8 aHffWYVzxlbvh037JlVhR8ERE/IxGWBZRv5qHj7bJk=; b=TKoMfHHkIQcef4oL9 WCvsrpW+mTxjtA3eu9J9hQdlSACakLolIy62RydRB3PnAitR2M2UBSxOg6u41jAQ orR8E5pfwsu4X5hri4xNT6JK2donC1MWsL/u0WbE7rRdrQQpndWHCmOLcrn85w5q SI+HqYSuDNwoKNY/0GBR6Pi4KU3xLzz6Q+JVFC40HVtSP3UyiF03OUmeTa8dDPt6 DcuHCt92Cd2YJ7SYU+vMYMh3KnIdv8pfwE/90UpO7I3xohC3Jy56VaPbigBQF9ob 6qBILVQxLXuHVd9mMl4KuNfCKXc+3cO+4irgJurxJUSavrvBRuwB40RYu4N6E0i6 RGNjg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvkeekvdehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofgjfhhrggfgsedtkeertdertddtnecuhfhrohhmpefpvghilheu rhhofihnuceonhgvihhlsgesohifnhhmrghilhdrnhgvtheqnecuggftrfgrthhtvghrnh epveevkeffudeuvefhieeghffgudektdelkeejiedtjedugfeukedvkeffvdefvddunecu vehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhlsg esohifnhhmrghilhdrnhgvthdpnhgspghrtghpthhtohephedupdhmohguvgepshhmthhp ohhuthdprhgtphhtthhopehvihhrohesiigvnhhivhdrlhhinhhugidrohhrghdruhhkpd hrtghpthhtoheplhhinhhugidqgihfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgt phhtthhopehlihhnuhigqdhunhhiohhnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhgpd hrtghpthhtoheplhhinhhugidqthhrrggtvgdqkhgvrhhnvghlsehvghgvrhdrkhgvrhhn vghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlh drohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgv lhdrohhrghdprhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrh hnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqvgigthegsehvghgvrhdrkhgvrhhn vghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlh drohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 12 Mar 2026 20:43:15 -0400 (EDT) From: NeilBrown To: Linus Torvalds , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Carlos Maiolino , Miklos Szeredi , Amir Goldstein , Jan Harkes , Hugh Dickins , Baolin Wang , David Howells , Marc Dionne , Steve French , Namjae Jeon , Sungjong Seo , Yuezhang Mo , Andreas Hindborg , Breno Leitao , "Theodore Ts'o" , Andreas Dilger , Steven Rostedt , Masami Hiramatsu , Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko , Tyler Hicks , Andreas Gruenbacher , Richard Weinberger , Anton Ivanov , Johannes Berg , Jeremy Kerr , Ard Biesheuvel Cc: linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-xfs@vger.kernel.org, linux-unionfs@vger.kernel.org, coda@cs.cmu.edu, linux-mm@kvack.org, linux-afs@lists.infradead.org, linux-cifs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, ceph-devel@vger.kernel.org, ecryptfs@vger.kernel.org, gfs2@lists.linux.dev, linux-um@lists.infradead.org, linux-efi@vger.kernel.org Subject: [PATCH 36/53] cephfs: remove d_alloc from CEPH_MDS_OP_LOOKUPNAME handling in ceph_fill_trace() Date: Fri, 13 Mar 2026 08:12:23 +1100 Message-ID: <20260312214330.3885211-37-neilb@ownmail.net> X-Mailer: git-send-email 2.50.0.107.gf914562f5916.dirty In-Reply-To: <20260312214330.3885211-1-neilb@ownmail.net> References: <20260312214330.3885211-1-neilb@ownmail.net> Reply-To: NeilBrown Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: NeilBrown When performing a get_name export_operation, ceph sends a LOOKUPNAME op to the server. When it gets a reply it tries to look up the name locally and if the name exists in the dcache with the wrong inode, it discards the result and tries again. If it doesn't find the name in the dcache it will allocate a new dentry and never make any use of it. The dentry is never instantiated and is assigned to ->r_dentry which is then freed by post-op cleanup. As this is a waste, and as there is a plan to remove d_alloc(), this code is discarded. Also try_lookup_noperm() is used in place of full_name_hash() and d_lookup(), and QSTR_LEN() is used to initialise dname. Signed-off-by: NeilBrown --- fs/ceph/inode.c | 29 +++++++---------------------- 1 file changed, 7 insertions(+), 22 deletions(-) diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c index 59f9f6948bb2..0982fbda2a82 100644 --- a/fs/ceph/inode.c +++ b/fs/ceph/inode.c @@ -15,6 +15,7 @@ #include #include #include +#include =20 #include "super.h" #include "mds_client.h" @@ -1623,33 +1624,17 @@ int ceph_fill_trace(struct super_block *sb, struct = ceph_mds_request *req) ceph_fname_free_buffer(parent_dir, &oname); goto done; } - dname.name =3D oname.name; - dname.len =3D oname.len; - dname.hash =3D full_name_hash(parent, dname.name, dname.len); + dname =3D QSTR_LEN(oname.name, oname.len); tvino.ino =3D le64_to_cpu(rinfo->targeti.in->ino); tvino.snap =3D le64_to_cpu(rinfo->targeti.in->snapid); retry_lookup: - dn =3D d_lookup(parent, &dname); + dn =3D try_lookup_noperm(&dname, parent); doutc(cl, "d_lookup on parent=3D%p name=3D%.*s got %p\n", parent, dname.len, dname.name, dn); - - if (!dn) { - dn =3D d_alloc(parent, &dname); - doutc(cl, "d_alloc %p '%.*s' =3D %p\n", parent, - dname.len, dname.name, dn); - if (!dn) { - dput(parent); - ceph_fname_free_buffer(parent_dir, &oname); - err =3D -ENOMEM; - goto done; - } - if (is_nokey) { - spin_lock(&dn->d_lock); - dn->d_flags |=3D DCACHE_NOKEY_NAME; - spin_unlock(&dn->d_lock); - } - err =3D 0; - } else if (d_really_is_positive(dn) && + if (IS_ERR(dn)) + /* should be impossible */ + dn =3D NULL; + if (dn && d_really_is_positive(dn) && (ceph_ino(d_inode(dn)) !=3D tvino.ino || ceph_snap(d_inode(dn)) !=3D tvino.snap)) { doutc(cl, " dn %p points to wrong inode %p\n", --=20 2.50.0.107.gf914562f5916.dirty