[PATCH 1/3] mm: Export vmf_insert_mixed_mkwrite()
Michael Kelley
mhklinux at outlook.com
Wed Apr 9 14:10:26 UTC 2025
From: Christoph Hellwig <hch at lst.de> Sent: Wednesday, April 9, 2025 3:50 AM
>
> On Tue, Apr 08, 2025 at 11:36:44AM -0700, mhkelley58 at gmail.com wrote:
> > From: Michael Kelley <mhklinux at outlook.com>
> >
> > 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
More information about the dri-devel
mailing list