lkml.org 
[lkml]   [2024]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v21 2/5] ring-buffer: Introducing ring-buffer mapping functions
From
On 24.04.24 22:31, Vincent Donnefort wrote:
> Hi David,
>
> Thanks for your quick response.
>
> On Wed, Apr 24, 2024 at 05:26:39PM +0200, David Hildenbrand wrote:
>>
>> I gave it some more thought, and I think we are still missing something (I
>> wish PFNMAP/MIXEDMAP wouldn't be that hard).
>>
>>> +
>>> +/*
>>> + * +--------------+ pgoff == 0
>>> + * | meta page |
>>> + * +--------------+ pgoff == 1
>>> + * | subbuffer 0 |
>>> + * | |
>>> + * +--------------+ pgoff == (1 + (1 << subbuf_order))
>>> + * | subbuffer 1 |
>>> + * | |
>>> + * ...
>>> + */
>>> +#ifdef CONFIG_MMU
>>> +static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
>>> + struct vm_area_struct *vma)
>>> +{
>>> + unsigned long nr_subbufs, nr_pages, vma_pages, pgoff = vma->vm_pgoff;
>>> + unsigned int subbuf_pages, subbuf_order;
>>> + struct page **pages;
>>> + int p = 0, s = 0;
>>> + int err;
>>> +
>>
>> I'd add some comments here like
>>
>> /* Refuse any MAP_PRIVATE or writable mappings. */
>>> + if (vma->vm_flags & VM_WRITE || vma->vm_flags & VM_EXEC ||
>>> + !(vma->vm_flags & VM_MAYSHARE))
>>> + return -EPERM;
>>> +
>>
>> /*
>> * Make sure the mapping cannot become writable later. Also, tell the VM
>> * to not touch these pages pages (VM_DONTCOPY | VM_DONTDUMP) and tell
>> * GUP to leave them alone as well (VM_IO).
>> */
>>> + vm_flags_mod(vma,
>>> + VM_MIXEDMAP | VM_PFNMAP |
>>> + VM_DONTCOPY | VM_DONTDUMP | VM_DONTEXPAND | VM_IO,
>>> + VM_MAYWRITE);
>>
>> I am still really unsure about VM_PFNMAP ... it's not a PFNMAP at all and,
>> as stated, vm_insert_pages() even complains quite a lot when it would have
>> to set VM_MIXEDMAP and VM_PFNMAP is already set, likely for a very good
>> reason.
>>
>> Can't we limit ourselves to VM_IO?
>>
>> But then, I wonder if it really helps much regarding GUP: yes, it blocks
>> ordinary GUP (see check_vma_flags()) but as insert_page_into_pte_locked()
>> does *not* set pte_special(), GUP-fast (gup_fast_pte_range()) will not
>> reject it.
>>
>> Really, if you want GUP-fast to reject it, remap_pfn_range() and friends are
>> the way to go, that will set pte_special() such that also GUP-fast will
>> leave it alone, just like vm_normal_page() would.
>>
>> So ... I know Linus recommended VM_PFNMAP/VM_IO to stop GUP, but it alone
>> won't stop all of GUP. We really have to mark the PTE as special, which
>> vm_insert_page() must not do (because it is refcounted!).
>
> Hum, apologies, I am not sure to follow the connection here. Why do you think
> the recommendation was to prevent GUP?

Ah, I'm hallucinating! :) "not let people play games with the mapping" to me
implied "make sure nobody touches it". If GUP is acceptable that makes stuff
a lot easier. VM_IO will block some GUP, but not all of it.

>
>>
>> Which means: do we really have to stop GUP from grabbing that page?
>>
>> Using vm_insert_page() only with VM_MIXEDMAP (and without VM_PFNMAP|VM_IO)
>> would be better.
>
> Under the assumption we do not want to stop all GUP, why not using VM_IO over
> VM_MIXEDMAP which is I believe more restrictive?

VM_MIXEDMAP will be implicitly set by vm_insert_page(). There is a lengthy comment
for vm_normal_page() that explains all this madness. VM_MIXEDMAP is primarily
relevant for COW mappings, which you just forbid completely.

remap_pfn_range_notrack() documents the semantics of some of the other flags:

* VM_IO tells people not to look at these pages
* (accesses can have side effects).
* VM_PFNMAP tells the core MM that the base pages are just
* raw PFN mappings, and do not have a "struct page" associated
* with them.
* VM_DONTEXPAND
* Disable vma merging and expanding with mremap().
* VM_DONTDUMP
* Omit vma from core dump, even when VM_IO turned off.

VM_PFNMAP is very likely really not what we want, unless we really perform raw
PFN mappings ... VM_IO we can set without doing much harm.

So I would suggest dropping VM_PFNMAP when using vm_insert_pages(), using only VM_IO
and likely just letting vm_insert_pages() set VM_MIXEDMAP for you.

[...]

>>
>> vm_insert_pages() documents: "In case of error, we may have mapped a subset
>> of the provided pages. It is the caller's responsibility to account for this
>> case."
>>
>> Which could for example happen, when allocating a page table fails.
>>
>> Would we able to deal with that here?
>
> As we are in the mmap path, on an error, I would expect the vma to be destroyed
> and those pages whom insertion succeeded to be unmapped?
>

Ah, we simply fail ->mmap().

In mmap_region(), if call_mmap() failed, we "goto unmap_and_free_vma" where we have

/* Undo any partial mapping done by a device driver. */
unmap_region(mm, &vmi.mas, vma, prev, next, vma->vm_start, vma->vm_end, vma->vm_end, true);


> But perhaps shall we proactively zap_page_range_single()?

No mmap_region() should indeed be handling it correctly already!

--
Cheers,

David / dhildenb


\
 
 \ /
  Last update: 2024-04-24 22:56    [W:0.074 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site