dmabuf: implement dma_buf_mmap_fileops#484
Open
yizishun wants to merge 1 commit into
Open
Conversation
As an fo_mmap handler, dma_buf_mmap_fileops() must produce a vm_object and insert a mapping into the target map. The previous version only filled a few fields of an uninitialized on-stack vm_area_struct and called the exporter's ->mmap callback, without ever creating an object, so mmap(2) on a dma-buf fd could not work. The implementation is similar to linux_file_mmap(), except that it reuses vma->vm_obj to give the exporter a channel to create its own vm_object. This is primarily meant for the udmabuf driver of my GSoC 2026 project. When the exporter does not create its own object, we fall back to letting dmabuf build an OBJT_DEVICE/MGTDEVICE/SGT object for it; those paths are not implemented yet. They are left unimplemented for two reasons. First, for now only udmabuf needs to mmap() a dma-buf fd. Second, the linux_file_mmap() model is questionable: vmf_insert_pfn() should carry OBJT_DEVICE/SGT semantics, but it is instead paired with OBJT_MGTDEVICE and grabs the page inside vmf_insert_pfn(). When the exporter has no page but only a pfn(paddr), or does not want others managing its pages, that does not fit the insert-pfn semantics -- it is really vmf_insert_page() semantics. For this reason udmabuf chooses to create its own vm_object.
20 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As an fo_mmap handler, dma_buf_mmap_fileops() must produce a vm_object and insert a mapping into the target map. The previous version only filled a few fields of an uninitialized on-stack vm_area_struct and called the exporter's ->mmap callback, without ever creating an object, so mmap(2) on a dma-buf fd could not work.
The implementation is similar to linux_file_mmap(), except that it reuses vma->vm_obj to give the exporter a channel to create its own vm_object. This is primarily meant for the udmabuf driver of my GSoC 2026 project. When the exporter does not create its own object, we fall back to letting dmabuf build an OBJT_DEVICE/MGTDEVICE/SGT object for it; those paths are not implemented yet.
They are left unimplemented for two reasons. First, for now only udmabuf needs to mmap() a dma-buf fd. Second, the linux_file_mmap() model is questionable: vmf_insert_pfn() should carry OBJT_DEVICE/SGT semantics, but it is instead paired with OBJT_MGTDEVICE and grabs the page inside vmf_insert_pfn(). When the exporter has no page but only a pfn(paddr), or does not want others managing its pages, that does not fit the insert-pfn semantics -- it is really vmf_insert_page() semantics. For this reason udmabuf chooses to create its own vm_object.