From nobody Tue Apr 7 16:16:37 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 241DB30FC29; Fri, 13 Mar 2026 00:48:24 +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=1773362905; cv=none; b=FfXDscDS/sEngEB/HT77iY/toZxY5fI51vrTdTXPNIQ7tmDG9qWONUGZzNAaAVjfBe+WdR7OnCnPMvt+IA3aIeqIzlaMn+OBSgi75iBEZDcgt0C2jvi1x8T2aNVXfiEdXN2uiHF60UntIi/GYBO9RmPPY2KeSBZJnWZshsrMli8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773362905; c=relaxed/simple; bh=bPb+bIqpK5hvVK2d8DMn3IwNAwWZ+dX19WhkeuUgfD4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NB8qeLjWgF7NV0K0DYYOpDvQZQFO/o5P827Rhld7kvJxLpLITSKLbvz50eNHGVNezye97Q/ESKaK/ya/MXFD78HyaMwTNsTK6ePJ6SS/7mnlYsuf6nDu/IRKDO4QlWjcQDSC+380ayL2ZdvMbsjOsw7z9SG202NM194ArGIBxkQ= 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=dN+zoQ+X; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=34dgo/VI; 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="dN+zoQ+X"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="34dgo/VI" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailflow.stl.internal (Postfix) with ESMTP id 723B61301B7D; Thu, 12 Mar 2026 20:48:22 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Thu, 12 Mar 2026 20:48:23 -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=1773362902; x=1773370102; bh=3OVL4XXP8pGkqIJaCgrneigzeg9lURjpYtnSBAI2TgY=; b= dN+zoQ+X4IMCOwHYdmkT/bGnzCHvuxlXBbrpp9O8UwCmnQeDDi7ioO7y2/TUY8l5 mQGtxsh3qVE4W70GI8wjUfwVDAFocwzcsunO2RHndj6ssUSoW5JU5xyWRUYJYDG9 NMIjn03yZHXunWH8BNEHahsglP7uOUYKduvq4RcsnRx45o5+YD6/oyA0D9GyutPP mLXDY4UxeKqfkDk1pTNpvWvnW1/dJJmaIfcBQR9lGPgKHB0zDYqbbg/WeD543BZ1 YZZiFH4HEkOT7GPsszH0tbfrqAMP2nkAl+SHWoXH2ZfgLfzJ7G8Da4TigmEpPMMB kWwgCUIZj7EH1b7QHZSsmw== 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=1773362902; x=1773370102; bh=3 OVL4XXP8pGkqIJaCgrneigzeg9lURjpYtnSBAI2TgY=; b=34dgo/VIKgtmzJGsl miC6lP3iQWBH1TiVT3V5XLsNBZ4hEoP69rm02c/9mKZc3HpddJ+Jm5BVWcJn9DkB 57t0tJJgDeHpeL+ua3mR8GhZPmEwPi0lQb3PwN14P92l/6Ep6Qp5LUxmLxKuHb0F wZYQlWii+7LBp+7LMX/8e2iuf/gsPxQRwWVKDTbZSMt9L0ZT01nsdAwc9YTMK1yk 3Ch2rxde/oduz5imnG5I61fP0o7Q2RmqJ7K3UEHPNtcBLNHsLWMstLaJPoAb0igY 8DF5fJdmXv6TlSvdhF6xHSluXNYiYlg4IeJQvDDCwPSoyDiP0Juj0NE2pRGV7aHr PQHYQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvkeekvdeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofgjfhhrggfgsedtkeertdertddtnecuhfhrohhmpefpvghilheu rhhofihnuceonhgvihhlsgesohifnhhmrghilhdrnhgvtheqnecuggftrfgrthhtvghrnh epteetteeuteffveduveetgfdtuedvfffhudetuefgffejgffhgffhgfetffetudeinecu ffhomhgrihhnpehsthgrthhushdruggrthgrnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepnhgvihhlsgesohifnhhmrghilhdrnhgvthdpnhgs pghrtghpthhtohephedupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehvihhroh esiigvnhhivhdrlhhinhhugidrohhrghdruhhkpdhrtghpthhtoheplhhinhhugidqgihf shesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhunhhioh hnfhhssehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqthhr rggtvgdqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplh hinhhugidqnhhfshesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhn uhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlih hnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtohep lhhinhhugidqvgigthegsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplh hinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: i9d664b8f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 12 Mar 2026 20:48:08 -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 19/53] afs: use d_time instead of d_fsdata Date: Fri, 13 Mar 2026 08:12:06 +1100 Message-ID: <20260312214330.3885211-20-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 afs uses ->d_fsdata to store version information for the parent directory. ->d_time is arguably a better field to store this information as the version is like a time stamp, and ->d_time is an unsigned long, while ->d_fsdata is a void *. This will leave ->d_fsdata free for a different use ... which admittedly is also not a void*, but is certainly not at all a time. Interesting the value stored in ->d_time or d_fsdata is u64 which is a different size of 32 bit hosts. Maybe that doesn't matter. Signed-off-by: NeilBrown --- fs/afs/dir.c | 18 +++++++++--------- fs/afs/internal.h | 8 ++++---- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/fs/afs/dir.c b/fs/afs/dir.c index 78caef3f1338..a0417292314c 100644 --- a/fs/afs/dir.c +++ b/fs/afs/dir.c @@ -808,7 +808,7 @@ static struct inode *afs_do_lookup(struct inode *dir, s= truct dentry *dentry) afs_dir_iterate(dir, &cookie->ctx, NULL, &data_version); } =20 - dentry->d_fsdata =3D (void *)(unsigned long)data_version; + dentry->d_time =3D (unsigned long)data_version; =20 /* Check to see if we already have an inode for the primary fid. */ inode =3D ilookup5(dir->i_sb, cookie->fids[1].vnode, @@ -895,9 +895,9 @@ static struct inode *afs_do_lookup(struct inode *dir, s= truct dentry *dentry) } =20 if (op->file[0].scb.have_status) - dentry->d_fsdata =3D (void *)(unsigned long)op->file[0].scb.status.data_= version; + dentry->d_time =3D (unsigned long)op->file[0].scb.status.data_version; else - dentry->d_fsdata =3D (void *)(unsigned long)op->file[0].dv_before; + dentry->d_time =3D (unsigned long)op->file[0].dv_before; ret =3D afs_put_operation(op); out: kfree(cookie); @@ -1010,7 +1010,7 @@ static struct dentry *afs_lookup(struct inode *dir, s= truct dentry *dentry, _debug("splice %p", dentry->d_inode); d =3D d_splice_alias(inode, dentry); if (!IS_ERR_OR_NULL(d)) { - d->d_fsdata =3D dentry->d_fsdata; + d->d_time =3D dentry->d_time; trace_afs_lookup(dvnode, &d->d_name, &fid); } else { trace_afs_lookup(dvnode, &dentry->d_name, &fid); @@ -1040,7 +1040,7 @@ static int afs_d_revalidate_rcu(struct afs_vnode *dvn= ode, struct dentry *dentry) * version. */ dir_version =3D (long)READ_ONCE(dvnode->status.data_version); - de_version =3D (long)READ_ONCE(dentry->d_fsdata); + de_version =3D (long)READ_ONCE(dentry->d_time); if (de_version !=3D dir_version) { dir_version =3D (long)READ_ONCE(dvnode->invalid_before); if (de_version - dir_version < 0) @@ -1100,7 +1100,7 @@ static int afs_d_revalidate(struct inode *parent_dir,= const struct qstr *name, * version. */ dir_version =3D dir->status.data_version; - de_version =3D (long)dentry->d_fsdata; + de_version =3D (long)dentry->d_time; if (de_version =3D=3D (long)dir_version) goto out_valid_noupdate; =20 @@ -1161,7 +1161,7 @@ static int afs_d_revalidate(struct inode *parent_dir,= const struct qstr *name, } =20 out_valid: - dentry->d_fsdata =3D (void *)(unsigned long)dir_version; + dentry->d_time =3D (unsigned long)dir_version; out_valid_noupdate: key_put(key); _leave(" =3D 1 [valid]"); @@ -1931,7 +1931,7 @@ static void afs_rename_edit_dir(struct afs_operation = *op) spin_unlock(&new_inode->i_lock); } =20 - /* Now we can update d_fsdata on the dentries to reflect their + /* Now we can update d_time on the dentries to reflect their * new parent's data_version. */ afs_update_dentry_version(op, new_dvp, op->dentry); @@ -2167,7 +2167,7 @@ static int afs_rename(struct mnt_idmap *idmap, struct= inode *old_dir, } =20 /* This bit is potentially nasty as there's a potential race with - * afs_d_revalidate{,_rcu}(). We have to change d_fsdata on the dentry + * afs_d_revalidate{,_rcu}(). We have to change d_time_ on the dentry * to reflect it's new parent's new data_version after the op, but * d_revalidate may see old_dentry between the op having taken place * and the version being updated. diff --git a/fs/afs/internal.h b/fs/afs/internal.h index 009064b8d661..106a7fe06b56 100644 --- a/fs/afs/internal.h +++ b/fs/afs/internal.h @@ -1746,17 +1746,17 @@ static inline struct inode *AFS_VNODE_TO_I(struct a= fs_vnode *vnode) } =20 /* - * Note that a dentry got changed. We need to set d_fsdata to the data ve= rsion + * Note that a dentry got changed. We need to set d_time to the data vers= ion * number derived from the result of the operation. It doesn't matter if - * d_fsdata goes backwards as we'll just revalidate. + * d_time goes backwards as we'll just revalidate. */ static inline void afs_update_dentry_version(struct afs_operation *op, struct afs_vnode_param *dir_vp, struct dentry *dentry) { if (!op->cumul_error.error) - dentry->d_fsdata =3D - (void *)(unsigned long)dir_vp->scb.status.data_version; + dentry->d_time =3D + (unsigned long)dir_vp->scb.status.data_version; } =20 /* --=20 2.50.0.107.gf914562f5916.dirty