Re: [PATCH] perf: map pages in advance

[David Hildenbrand]

On 29.11.24 15:35, Lorenzo Stoakes wrote:
> On Fri, Nov 29, 2024 at 03:09:49PM +0100, David Hildenbrand wrote:
> > > > > I just tested it and write() works fine, it uses uaccess afaict as part of the
> > > > > lib/iov_iter.c code:
> > > > >
> > > > > generic_perform_write()
> > > > > -> copy_folio_from_iter_atomic()
> > > > > -> copy_page_from_iter_atomic()
> > > > > -> __copy_from_iter()
> > > > > -> copy_from_user_iter()
> > > > > -> raw_copy_from_user()
> > > > > -> copy_user_generic()
> > > > > -> [uaccess asm]
> > > >
> > > > Ah yes. O_DIRECT is the problematic bit I suspect, which will use GUP.
> > > >
> > > > Ptrace access and friends should also no longer work on these pages, likely
> > > > that's tolerable.
> > >
> > > Yeah Peter can interject if not, but I'd be _very_ surprised if anybody expects
> > > to be able to ptrace perf counter mappings in another process (it'd be kind of
> > > totally insane to do that anyway since it's a ring buffer that needs special
> > > handing anyway).
> >
> > I think so as well. Disallowing GUP has some side effects, like not getting
> > these pages included in a coredump etc ... at least I hope nobody uses
> > O_DIRECT on them.
>
> We set VM_DONTDUMP anyway (set by remap_pfn_range() also) so this part won't be
> a problem, and I can't see anybody using O_DIRECT on them, sensibly.

Ah, even better.

> > Actually, the whole thing is on my todo list, because messing with the RMAP
> > with vm_insert_pages() doesn't make any sense (whereby the refcount might!).
> > See the TODO I added in __folio_rmap_sanity_checks().
>
> How long is your TODO list I wonder? :)) I imagine it requires a huge page to
> map at this point..

:D

Too long, but as some of these TODOs stand in the memdesc way, 
fortunately other people might be able to give a helping hand at some 
point ;)

I'll play with using a page type for some of these "simple" cases and 
see how hard it will get.

> > --
> > Cheers,
> >
> > David / dhildenb
>
> Cool will respin and send out shortly with an appropriately 'forgive us father
> for we have sinned' comment.
>
> Thanks for taking the time to discuss this! Much appreciated.

Thanks for bearing with me. Whenever PFNMAP/MIXEDMAP is involved it gets 
tricky, and as soon as PFNMAP/MIXEDMAP is inevitable, things get ugly. :)

--
Cheers,

David / dhildenb