linux-kernel - Re: [PATCH] fs/9p: delete unnnecessary condition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <73432e36-de5b-48fb-b314-052b2668bb8e@maowtm.org>
Date: Sat, 25 Oct 2025 16:39:10 +0100
From: Tingmao Wang <m@...wtm.org>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: Christian Schoenebeck <linux_oss@...debyte.com>,
 Eric Van Hensbergen <ericvh@...nel.org>,
 Dan Carpenter <dan.carpenter@...aro.org>, Latchesar Ionkov
 <lucho@...kov.net>, Mickaël Salaün <mic@...ikod.net>,
 v9fs@...ts.linux.dev, linux-kernel@...r.kernel.org,
 kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] fs/9p: delete unnnecessary condition

On 10/24/25 14:34, Dominique Martinet wrote:
> [...]
> Anyway, thanksfully this particular double retval < 0 check is harmless
> -- I'll pick this up for -next for now but hopefully we'll be able to
> "revert the revert" and fix the other problems Tingmao pointed out by
> the time we reach the 6.19 merge window...

I'm hoping that the solution I proposed [1], which is to pass
V9FS_STAT2INODE_KEEP_ISIZE in v9fs_refresh_inode_dotl if v9ses->cache &
(CACHE_LOOSE | CACHE_WRITEBACK), would be good enough to prevent these
sorts of issues.  But given I've already missed a thing the first time,
I'm less confident in my judgement now 😅

(The other alternative I see is to flush the cache before updating
metadata, like we do in v9fs_vfs_getattr, but then that's a even larger
change, and I'm also not sure if it would be race-free (i.e. if another
write is processed after we flush but before we refresh metadata))

I can try and do some more testing on this, and would welcome pointers on
things to try.  Also let me know if you think the above suggestion
(V9FS_V9FS_STAT2INODE_KEEP_ISIZE) is safe on its own.

(Also, for some context, the main victim of this stale metadata issue,
afaik, is just the workaround for Landlock to work on 9pfs, in which we
get something to deliberately hold the paths used in rules open for the
inode to be reused.  Although I guess some other workloads which do a
similar thing might also suffer from this so still good to get this (stale
metadata issue) fixed.  I hope we eventually come to a proper solution for
the Landlock issue tho)

[1]: https://lore.kernel.org/all/6c74ad63-3afc-4549-9ac6-494b9a63e839@maowtm.org/