From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (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 03B0715A8; Thu, 4 Sep 2025 00:05:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756944328; cv=none; b=t6C2+KHTMBijWbbEcvPe/8qdV7lUIa23g+6gaHwaGo61UQURMWoGtauKe0qarkYFlMPzpofrl691l7M9Gd9+T0QTJgAIn9LEEsCrabc/WnmS+pNmUxdUiv6p0PAEY5LUkEVkpcgVJMxVIXHWMTBvk+ruSZSBSpT33AxGVguVW+8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756944328; c=relaxed/simple; bh=scZFTBZe7gJCYcNArW/RUUcEk9zABjvDgsI1g9xjiao=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W6BsGSU5zf/S3Hd1Q+QONaVfwb+H1lZKkBx9RWrJW9gi/CI9Fxz0SuZEbrp3En06a72hWcUXLhdGGOgo8Yy3UIuvHlNeB9IzviHkJ5re7RM1JIJdv4XmL+C696BBh/tguzE0E4JbpdcJi2NosRFsLQuVhp0dFCK+6C5UOyHE8lo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=maowtm.org; spf=pass smtp.mailfrom=maowtm.org; dkim=pass (2048-bit key) header.d=maowtm.org header.i=@maowtm.org header.b=2yz4JvwB; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=EACHuVub; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=maowtm.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=maowtm.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=maowtm.org header.i=@maowtm.org header.b="2yz4JvwB"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="EACHuVub" Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id 6911B1400182; Wed, 3 Sep 2025 20:05:26 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Wed, 03 Sep 2025 20:05:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maowtm.org; 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:subject:subject:to:to; s=fm1; t=1756944326; x= 1757030726; bh=CsbRYtdoTrEOgTKUCcI1TPZdtkoXWLEquNG3Qonu8b4=; b=2 yz4JvwBqWakE+ojmyqXssZL9Q/Fd0kzHBfyn/wyoFtcfiSbwRqvGdD9x3jIRi+OJ RNC8YyLn7FDhp0mg019ryoDyxEWs3HsPbv49cbgh1GGo9oMqAWLcQbYMYm+uTxxY g/qEyjvqfS+AZKYjHlfrrOdQFhwU9+xF2BBGoEgAQTzEjRdzoOlDYduN/hY7hrvd 2oMpfOSfIFCj9G1uUfX5P6YmJHo9YEKWKDr8rMW3CvQ3wmzVGeBoiK2mjRU4NG9B t3fbprrYxfyTje/Npm4eb0BsoqDBjFfmkghxJIbErkdMlbDBrHyd6rfkkrQ2vbHF XDNAzXPl8iRnqfESPYdEg== 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:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1756944326; x=1757030726; bh=C sbRYtdoTrEOgTKUCcI1TPZdtkoXWLEquNG3Qonu8b4=; b=EACHuVubK01IPB6Rw VgMTwOv4AUxWMJSkv4UWUngzaYJsBFiHxcA4i7mShZpYdgyVIsjQYbbNOlQvsKM/ 0a1pcHn0whLzUaUUs8ESectl2H0hikgBHIn+kyqisJcB3RsR9SpTJyy1rsV7w8ls UzrUy4C5ae0cgA2mX4tFR8Hywiz/eMR4am/u7RaSlt+6L0uU0eugKh02nhpHUvxh i9kFOSGE0Jx4oWXwkNpFLvjTahNumutN9JUMJ+4L7CIeIWLinzyWoZVPzOEOr80Z YMv0seNmgKio+qfBe+Hfq0SphqwC4kvcS86lmVtRgzQQ6hmTDmBfIrtiM3WrDK0J omNOQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdegheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh ephffvvefufffkofgjfhgggfestdekredtredttdenucfhrhhomhepvfhinhhgmhgrohcu hggrnhhguceomhesmhgrohifthhmrdhorhhgqeenucggtffrrghtthgvrhhnpeeuuddthe fhhefhvdejteevvddvteefffegteetueegueeljeefueekjeetieeuleenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsehmrghofihtmhdroh hrghdpnhgspghrtghpthhtohepudegpdhmohguvgepshhmthhpohhuthdprhgtphhtthho pegrshhmrgguvghushestghouggvfihrvggtkhdrohhrghdprhgtphhtthhopegvrhhitg hvhheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhutghhohesihhonhhkohhvrdhn vghtpdhrtghpthhtoheplhhinhhugigpohhsshestghruhguvggshihtvgdrtghomhdprh gtphhtthhopehmihgtseguihhgihhkohgurdhnvghtpdhrtghpthhtohepmhesmhgrohif thhmrdhorhhgpdhrtghpthhtohepvhelfhhssehlihhsthhsrdhlihhnuhigrdguvghvpd hrtghpthhtohepghhnohgrtghksehgohhoghhlvgdrtghomhdprhgtphhtthhopehlihhn uhigqdhsvggtuhhrihhthidqmhhoughulhgvsehvghgvrhdrkhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i580e4893:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 3 Sep 2025 20:05:24 -0400 (EDT) From: Tingmao Wang To: Dominique Martinet , Eric Van Hensbergen , Latchesar Ionkov , Christian Schoenebeck , =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= Cc: Tingmao Wang , v9fs@lists.linux.dev, =?UTF-8?q?G=C3=BCnther=20Noack?= , linux-security-module@vger.kernel.org, Jan Kara , Amir Goldstein , Matthew Bobrowski , Al Viro , linux-fsdevel@vger.kernel.org Subject: [PATCH v2 4/7] fs/9p: .L: Refresh stale inodes on reuse Date: Thu, 4 Sep 2025 01:04:14 +0100 Message-ID: <717c1ede692e9d7fae9033cfbb59c68d7aecc9ba.1756935780.git.m@maowtm.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This uses the stat struct we already got as part of lookup process to refresh the inode "for free". Only for uncached mode for now. We will need to revisit this for cached mode once we sort out reusing an old inode with changed qid.version. (Currently this is not done in this series, which would be fine unless server side change happens, which is not supposed to happen in cached mode anyway) Note that v9fs_test_inode_dotl already makes sure we don't reuse inodes of the wrong type or different qid. Signed-off-by: Tingmao Wang --- Changes since v1: - Check cache bits instead of using `new` - uncached mode now also have new=0. fs/9p/vfs_inode_dotl.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c index 86adaf5bcc0e..d008e82256ac 100644 --- a/fs/9p/vfs_inode_dotl.c +++ b/fs/9p/vfs_inode_dotl.c @@ -164,6 +164,7 @@ static struct inode *v9fs_qid_iget_dotl(struct super_block *sb, .dentry = dentry, .need_double_check = false, }; + bool cached = v9ses->cache & (CACHE_META | CACHE_LOOSE); if (new) test = v9fs_test_new_inode_dotl; @@ -203,8 +204,21 @@ static struct inode *v9fs_qid_iget_dotl(struct super_block *sb, if (!inode) return ERR_PTR(-ENOMEM); - if (!(inode->i_state & I_NEW)) + if (!(inode->i_state & I_NEW)) { + /* + * If we're returning an existing inode, we might as well refresh + * it with the metadata we just got. Refreshing the i_size also + * prevents read errors. + * + * We only do this for uncached mode, since in cached move, any + * change on the inode will bump qid.version, which will result in + * us getting a new inode in the first place. If we got an old + * inode, let's not touch it for now. + */ + if (!cached) + v9fs_stat2inode_dotl(st, inode, 0); return inode; + } /* * initialize the inode with the stat info * FIXME!! we may need support for stale inodes -- 2.51.0