| Message ID | 20250408183646.1410-2-mhklinux@outlook.com |
|---|---|
| State | New |
| Headers | show |
| Series | fbdev: Add deferred I/O support for contiguous kernel memory framebuffers | expand |
On Tue, Apr 08, 2025 at 11:36:44AM -0700, mhkelley58@gmail.com wrote: > From: Michael Kelley <mhklinux@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. > 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.
From: Christoph Hellwig <hch@lst.de> Sent: Wednesday, April 9, 2025 3:50 AM > > On Tue, Apr 08, 2025 at 11:36:44AM -0700, mhkelley58@gmail.com wrote: > > From: Michael Kelley <mhklinux@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
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. > > 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. > But must the same treatment be applied to memory from > alloc_pages()? This is where I need some education. No, that's just fine.
From: Christoph Hellwig <hch@lst.de> 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.
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