Re: [PATCH] perf: map pages in advance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux