linux-kernel - Re: [GIT PULL] 9p cache=mmap regression fix (for 6.18-rc3)

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aPhtxt7qEWY5FjPQ@codewreck.org>
Date: Wed, 22 Oct 2025 14:38:14 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
	Tingmao Wang <m@...wtm.org>
Cc: Song Liu <song@...nel.org>, Andrii Nakryiko <andrii.nakryiko@...il.com>,
	Eric Van Hensbergen <ericvh@...nel.org>,
	Latchesar Ionkov <lucho@...kov.net>,
	Christian Schoenebeck <linux_oss@...debyte.com>,
	Alexei Starovoitov <ast@...nel.org>, linux-kernel@...r.kernel.org,
	v9fs@...ts.linux.dev, bpf@...r.kernel.org
Subject: Re: [GIT PULL] 9p cache=mmap regression fix (for 6.18-rc3)

Tingmao Wang wrote on Wed, Oct 22, 2025 at 12:34:13AM +0100:
> On 10/22/25 00:16, Dominique Martinet wrote:
> > We had a regression with cache=mmap that impacted quite a few people so
> > I'm sending a fix less than a couple of hours after making the commit.
> > 
> > If it turns out there are other side effects I'd suggest just reverting
> > commit 290434474c33 ("fs/9p: Refresh metadata in d_revalidate for
> > uncached mode too") first, but the fix is rather minimal so I think it's
> > ok to try falling forward -- let me know if you prefer a revert and I'll
> > send one instead (there's a minor conflict)
> 
> See the reply to the original patch [1] (posted right after, and before
> seeing, this message) - there is indeed more side effects, and I wouldn't
> mind a revert for now.  0172a934747f ("fs/9p: Invalidate dentry if inode
> type change detected in cached mode") will need to be reverted too.

(yeah, and even that conflicts due to the added debug message in the
next commit, but I went the heavy-handed way and removed the conflicting
hunk so that commit's also implicitly been removed. In hindsight it
would have been cleaner to revert the three commits
290434474c33^..c667c54c5875 -- ohwell)

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

OK, so let's go with the revert for now as I don't have time to look for
more corner cases immediately.

Linus, here's the new PR:
---------
The following changes since commit 211ddde0823f1442e4ad052a2f30f050145ccada:

  Linux 6.18-rc2 (2025-10-19 15:19:16 -1000)

are available in the Git repository at:

  https://github.com/martinetd/linux tags/9p-for-6.18-rc3-v2

for you to fetch changes up to 43c36a56ccf6d9b07b4b3f4f614756e687dcdc01:

  Revert "fs/9p: Refresh metadata in d_revalidate for uncached mode too" (2025-10-22 14:25:27 +0900)

----------------------------------------------------------------
Fix 9p cache=mmap regression by revert

This reverts the problematic commit instead of trying to fix it in a
rush

----------------------------------------------------------------
Dominique Martinet (1):
      Revert "fs/9p: Refresh metadata in d_revalidate for uncached mode too"

 fs/9p/vfs_dentry.c     | 10 ++--------
 fs/9p/vfs_inode.c      |  8 +-------
 fs/9p/vfs_inode_dotl.c |  8 +-------
 3 files changed, 4 insertions(+), 22 deletions(-)

-- 
Dominique Martinet | Asmadeus