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

[Dominique Martinet <asmadeus@codewreck.org>]

Adding David/Willy to recpients as I'm not 100% up to date on folios

Andrii Nakryiko wrote on Wed, Oct 23, 2024 at 09:56:06AM -0700:
> > 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.

(looks like 3c217a182018 ("selftests/bpf: add build ID tests") wasn't in
yet on the 9p multipage folios commit)

> 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.

That's probably obvious but I guess the selftest runs the binary
directly from a 9p mount?

> 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)?

Unless David/Willy has a solution immediately I'd say let's take the time to
sort this out and revert that commit for now -- I'll send a revert patch
immediately and submit it to Linus on Saturday.

Conceptually I guess something is broken with MADV_PAGEOUT on >1 page
folio, perhaps it's only evicting folios if the whole folio is in range
but it should evict any folio that touches the range or something?

Sorry I don't have time to dig further here, hopefully that's not too
difficult to handle and we can try again in rc1 proper of another cycle,
I shouldn't have sent that this late.


(leaving full text below for new recipients)
> 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(-)
> > 
> 

Thanks,
-- 
Dominique Martinet | Asmadeus