Received-SPF: pass (google.com: domain of linux-kernel+bounces-158920-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Thu, 25 Apr 2024 17:42:46 +0100
From: Vincent Donnefort <vdonnefort@google.com>
To: David Hildenbrand <david@redhat.com>
Cc: rostedt@goodmis.org, mhiramat@kernel.org, linux-kernel@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com,
	kernel-team@android.com, rdunlap@infradead.org, rppt@kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v21 2/5] ring-buffer: Introducing ring-buffer mapping
 functions
Message-ID: <ZiqIBo4sX-oAgj2M@google.com>
References: <20240423232728.1492340-1-vdonnefort@google.com>
 <20240423232728.1492340-3-vdonnefort@google.com>
 <f972ce5a-0351-450c-98a2-38188eae5001@redhat.com>
 <ZilsIJYbJ-JN4elq@google.com>
 <04137a08-8918-422c-8512-beb2074a427e@redhat.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <04137a08-8918-422c-8512-beb2074a427e@redhat.com>

On Wed, Apr 24, 2024 at 10:55:54PM +0200, David Hildenbrand wrote:
> 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.

Sounds good, I will do that in v22.

> 
> [...]
> 
> > > 
> > > 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!

Ok, thanks for confirming!

> 
> -- 
> Cheers,
> 
> David / dhildenb
>