On 29.11.24 14:02, Lorenzo Stoakes wrote:
On Fri, Nov 29, 2024 at 01:59:01PM +0100, David Hildenbrand wrote:
On 29.11.24 13:55, Lorenzo Stoakes wrote:
On Fri, Nov 29, 2024 at 01:45:42PM +0100, David Hildenbrand wrote:
On 29.11.24 13:26, Peter Zijlstra wrote:
On Fri, Nov 29, 2024 at 01:12:57PM +0100, David Hildenbrand wrote:
Well, I think we simply will want vm_insert_pages_prot() that stops treating
these things like folios :) . *likely* we'd want a distinct memdesc/type.
We could start that work right now by making some user (iouring,
ring_buffer) set a new page->_type, and checking that in
vm_insert_pages_prot() + vm_normal_page(). If set, don't touch the refcount
and the mapcount.
Because then, we can just make all the relevant drivers set the type, refuse
in vm_insert_pages_prot() anything that doesn't have the type set, and
refuse in vm_normal_page() any pages with this memdesc.
Maybe we'd have to teach CoW to copy from such pages, maybe not. GUP of
these things will stop working, I hope that is not a problem.
Well... perf-tool likes to call write() upon these pages in order to
write out the data from the mmap() into a file.
I'm confused about what you mean, write() using the fd should work fine, how
would they interact with the mmap? I mean be making a silly mistake here
write() to file from the mmap()'ed address range to *some* file.
Yeah sorry my brain melted down briefly, for some reason was thinking of read()
writing into the buffer...
This will GUP the pages you inserted.
GUP does not work on PFNMAP.
Well it _does_ if struct page **pages is set to NULL :)
Hm? :)
check_vma_flags() unconditionally refuses VM_PFNMAP.
--
Cheers,
David / dhildenb
