linux-kernel - Re: [GIT PULL] 9p fixes for 6.12-rc4

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: <20241023165606.3051029-1-andrii@kernel.org>
Date: Wed, 23 Oct 2024 09:56:06 -0700
From: Andrii Nakryiko <andrii@...nel.org>
To: asmadeus@...ewreck.org
Cc: ericvh@...nel.org,
	linux-kernel@...r.kernel.org,
	linux_oss@...debyte.com,
	pedro.falcato@...il.com,
	regressions@...mhuis.info,
	torvalds@...ux-foundation.org,
	v9fs@...ts.linux.dev,
	bpf@...r.kernel.org
Subject: Re: [GIT PULL] 9p fixes for 6.12-rc4

> The following changes since commit 98f7e32f20d28ec452afb208f9cffc08448a2652:
>
>   Linux 6.11 (2024-09-15 16:57:56 +0200)
>
> are available in the Git repository at:
> 
>   https://github.com/martinetd/linux tags/9p-for-6.12-rc4
> 
> for you to fetch changes up to 79efebae4afc2221fa814c3cae001bede66ab259:
>
>   9p: Avoid creating multiple slab caches with the same name (2024-09-23 05:51:27 +0900)
>
> ----------------------------------------------------------------
> Mashed-up update that I sat on too long:
> 
> - fix for multiple slabs created with the same name
> - enable multipage folios
> - theorical fix to also look for opened fids by inode if none
> was found by dentry
> 
> ----------------------------------------------------------------
> David Howells (1):
>      9p: Enable multipage folios

Are there any known implications of this change on madvise()'s MADV_PAGEOUT
behavior? After most recent pull from Linus's tree, one of BPF selftests
started failing. Bisection points to:

  9197b73fd7bb ("Merge tag '9p-for-6.12-rc4' of https://github.com/martinetd/linux")

... which is just an empty merge commit. So the "9p: Enable multipage folios"
by itself doesn't cause any regression, but when merged with the rest of the
code it does. I confirmed by reverting
1325e4a91a40 ("9p: Enable multipage folios"), after which the test in question
is succeeding again.

The test in question itself is a bit involved, but what it ultimately tries to
do is to ensure that part of ELF file containing build ID is paged out to cause
BPF helper to fail to retrieve said build ID (due to non-faulable context).

For that, we use the following sequence in target binary and process:

madvise(addr, page_sz, MADV_POPULATE_READ);
madvise(addr, page_sz, MADV_PAGEOUT);

First making sure page is paged in, then paged out. We make sure that build ID
is memory mapped in a separate segment with its own single-page memory mapping.
No changes or regressions there. No huge pages seem to be involved.

It used to work reliably, now it doesn't work. Any clue why or what should we
do differently to make sure that memory page with build ID information is not
paged in (reliably)?

Thanks!

P.S. The target binary and madvise() manipulations are at:

  tools/testing/selftests/bpf/uprobe_multi.c, see trigger_uprobe()

The test itself in BPF selftest is at:

  tools/testing/selftests/bpf/prog_tests/build_id.c, see subtest_nofault(),
  build_id_resident is false in this case.

>
> Dominique Martinet (1):
>       9p: v9fs_fid_find: also lookup by inode if not found dentry
> 
> Pedro Falcato (1):
>       9p: Avoid creating multiple slab caches with the same name
> 
>  fs/9p/fid.c       |  5 ++---
>  fs/9p/vfs_inode.c |  1 +
>  net/9p/client.c   | 10 +++++++++-
>  3 files changed, 12 insertions(+), 4 deletions(-)
> 
> -- 
> Dominique Martinet | Asmadeus