[1/3] mm: Export vmf_insert_mixed_mkwrite()

Commit Message

Michael Kelley April 8, 2025, 6:36 p.m. UTC

From: Michael Kelley <[e-mail]>

Export vmf_insert_mixed_mkwrite() for use by fbdev deferred I/O code,
which can be built as a module. For consistency with the related function
vmf_insert_mixed(), export without the GPL qualifier.

Commit cd1e0dac3a3e ("mm: unexport vmf_insert_mixed_mkwrite") is
effectively reverted.

Signed-off-by: Michael Kelley <[e-mail]>
---
 mm/memory.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Michael Kelley April 9, 2025, 2:10 p.m. UTC | #1

From: Christoph Hellwig <[e-mail]> Sent: Wednesday, April 9, 2025 3:50 AM
> 
> On Tue, Apr 08, 2025 at 11:36:44AM -0700, [e-mail] wrote:
> > From: Michael Kelley <[e-mail]>
> >
> > Export vmf_insert_mixed_mkwrite() for use by fbdev deferred I/O code,
> 
> But they are using this on dma coherent memory, where you can't legally
> get at the page.  As told last time you need to fix that first before
> hacking around that code.

Hmmm. What's the reference to "as told last time"? I don't think I've had
this conversation before.

For the hyperv_fb driver, the memory in question is allocated with a direct call
to alloc_pages(), not via dma_alloc_coherent(). There's no DMA in this scenario.
The memory is shared with the Hyper-V host and designated as the memory
for the virtual framebuffer device. It is then mapped into user space using the
mmap() system call against /dev/fb0. User space writes to the memory are
eventually (and I omit the details) picked up by the Hyper-V host and displayed.

Is your point that memory dma_alloc_coherent() memory must be treated as
a black box, and can't be deconstructed into individual pages? If so, that makes
sense to me. But must the same treatment be applied to memory from
alloc_pages()? This is where I need some education.

> 
> > which can be built as a module. For consistency with the related function
> > vmf_insert_mixed(), export without the GPL qualifier.
> 
> No.  All advanced new Linux functionality must be _GPL.  Don't try to
> sneak around that.

No problem. Just trying to be consistent, not sneak around anything.

Thanks,

Michael

Michael Kelley April 11, 2025, 3:40 a.m. UTC | #2

From: Christoph Hellwig <[e-mail]> Sent: Thursday, April 10, 2025 12:42 AM
> 
> On Wed, Apr 09, 2025 at 02:10:26PM +0000, Michael Kelley wrote:
> > Hmmm. What's the reference to "as told last time"? I don't think I've had
> > this conversation before.
> 
> Hmm, there was a conversation about deferred I/O, and I remember the
> drm folks even defending their abuse of vmalloc_to_page on dma coherent
> memory against the documentation in the most silly way.  Maybe that was
> a different discussion of the same thing.

Yes, must have been a different discussion.

Turns out the hyperv_fb driver in a different configuration *is* using
dma_alloc_coherent() to get framebuffer memory, which is then managed
by deferred I/O. dma_alloc_coherent() is used as a wrapper around
cma_alloc() but only when the framebuffer size is > 4 MiB. The deferred
I/O code doesn't do vmalloc_to_page() since the CPU address from
dma_alloc_coherent() isn't a vmalloc addr.

That combo works OK, so wasn't something to be fixed in this patch set.
I'll see about a separate patch to just use cma_alloc() directly for that
case, though cma_alloc() and cma_release() would need to be EXPORTed.

> 
> >
> > For the hyperv_fb driver, the memory in question is allocated with a direct call
> > to alloc_pages(), not via dma_alloc_coherent(). There's no DMA in this scenario.
> > The memory is shared with the Hyper-V host and designated as the memory
> > for the virtual framebuffer device. It is then mapped into user space using the
> > mmap() system call against /dev/fb0. User space writes to the memory are
> > eventually (and I omit the details) picked up by the Hyper-V host and displayed.
> 
> Oh, great.
> 
> > Is your point that memory dma_alloc_coherent() memory must be treated as
> > a black box, and can't be deconstructed into individual pages? If so, that makes
> > sense to me.
> 
> Yes.

I'll add some comments to the fbdev deferred I/O code saying not to use it
with a framebuffer allocated with dma_alloc_coherent().

Thanks,

Michael

> 
> > But must the same treatment be applied to memory from
> > alloc_pages()? This is where I need some education.
> 
> No, that's just fine.

Patch

diff --git a/mm/memory.c b/mm/memory.c
index 9d0ba6fe73c1..883ad53d077e 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2660,6 +2660,7 @@  vm_fault_t vmf_insert_mixed_mkwrite(struct vm_area_struct *vma,
 {
 	return __vm_insert_mixed(vma, addr, pfn, true);
 }
+EXPORT_SYMBOL(vmf_insert_mixed_mkwrite);
 
 /*
  * maps a range of physical memory into the requested pages. the old