Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

16 participants
3709 discussions

Re: [PATCH v2 01/23] dt-bindings: display: msm: Add Qualcomm DCP

by Rob Herring

On Wed, Nov 11, 2026 at 12:40:05PM +0530, Jayant Shekhar wrote: > > On 27-10-2026 01:14, Rob Herring (Arm) wrote: > > On Mon, 26 Oct 2026 11:51:11 +0530, Jayant Shekhar wrote: > > > DCP platforms place the display pipeline under firmware control, so Linux > > > cannot discover display resources through direct register access. The DRM > > > driver therefore needs device-tree descriptions of the Qualcomm transport > > > wrapper, display topology, IOMMU contexts, and panel connections. > > > > > > Add bindings for the Qualcomm DCP transport wrapper and VirtIO display > > > subsystem. Document the IPCC power-notify resources, transport and > > > framebuffer IOMMU contexts, firmware-visible IOVA range, INTF graph, and > > > DSI panel connections. The wrapper creates a standard VirtIO-MMIO child > > > after the IPCC power-notify sequence has completed. > > > > > > Assisted-by: LLM > > > Signed-off-by: Jayant Shekhar <jayant.shekhar(a)oss.qualcomm.com> > > > --- > > > .../bindings/display/msm/qcom,dcp-dsi.yaml | 79 ++++++++++++ > > > .../devicetree/bindings/display/msm/qcom,dcp.yaml | 123 +++++++++++++++++++ > > > .../bindings/virtio/qcom,dcp-virtio.yaml | 132 +++++++++++++++++++++ > > > 3 files changed, 334 insertions(+) > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > yamllint warnings/errors: > > > > dtschema/dtc warnings/errors: > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/virtio/qcom,dcp-virtio.yaml: iommu-ranges: multiple incompatible types: uint32-array > > /usr/local/lib/python3.13/dist-packages/dtschema/schemas/iommu/iommu.yaml: iommu-ranges: multiple incompatible types: uint32-matrix > > Could not decode node virtio@9be8000 property iommu-ranges with value b'\x00\x00\x00\x00\x84\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00' > > > > Traceback (most recent call last): > > File "/usr/local/bin/dt-validate", line 8, in <module> > > sys.exit(main()) > > ~~~~^^ > > File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 443, in main > > dtb_diagnostics = sg.check_dtb(filename) > > File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 331, in check_dtb > > dt = self.validator.decode_dtb(f.read(), decode_errors) > > File "/usr/local/lib/python3.13/dist-packages/dtschema/validator.py", line 631, in decode_dtb > > return [dtschema.dtb.fdt_unflatten(self, dtb)] > > ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^ > > File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 591, in fdt_unflatten > > dt = fdt_scan_node(validator, fdt, '/', offset) > > File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 320, in fdt_scan_node > > node = fdt_scan_node(validator, fdt, nodename, offset) > > File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 320, in fdt_scan_node > > node = fdt_scan_node(validator, fdt, nodename, offset) > > File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 312, in fdt_scan_node > > node_dict = node_props(validator, fdt, nodename, offset) > > File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 258, in node_props > > props_dict[p.name] = prop_value(validator, nodename, p) > > ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^ > > File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb.py", line 185, in prop_value > > if len(p) / type_format[fmt].size >= min_dim: > > ~~~~~~~~~~~^^^^^ > > KeyError: 'uint32-array' > > > > doc reference errors (make refcheckdocs): > > > > See https://patchwork.kernel.org/project/devicetree/patch/20261026-jshekhar-dcp… > > > > The base for the series is generally the latest rc1. A different dependency > > should be noted in *this* patch. > > > > If you already ran 'make dt_binding_check' and didn't see the above > > error(s), then make sure 'yamllint' is installed and dt-schema is up to > > date: > > > > pip3 install dtschema --upgrade > > > > Please check and re-submit after running the above command yourself. Note > > that DT_SCHEMA_FILES can be set to your schema file to speed up checking > > your schema. However, it must be unset to test all examples with your schema. > > > There is a dependent patch which adds iommu-ranges, I had tried with that > locally and it passes. Where in the patch does it say that? The maintainer applying this series needs to know about the dependency, hence the report. b4 provides for ways to define the base and any dependencies. Use that and then you won't get this report. Rob

5 hours, 28 minutes

[PATCH v13 00/19] PCI/P2PDMA: Route peer-to-peer DMA by TLP class

by Leon Romanovsky

Punch line for Linus from Jason: "Enhance detecting if the PCI fabric can support a peer to peer path by evaluating the full bi-directional fabric path over each of the three traffic type ACS controls. Expand the number of fabric configurations where the P2P algorithm makes the correct determination of support to include non-uniform ACS and situations where translated takes different routes from untranslated." -------------------------------------------------------------------------- PCI P2PDMA applies Request and Completion Redirect throughout both paths. This misclassifies asymmetric and nested switches, and reports one answer for every kind of TLP. Three ACS controls act on TLP attributes the Requester chooses rather than on the topology: Translation Blocking and Direct Translated P2P act on a Request's Address Type, and Completion Redirect skips Completions carrying Relaxed Ordering. Evaluate each direction at the path divergence, decide every class from the one walk, and treat a client with ATS enabled as translating unless its driver declares per-mapping ATS. This completes the P2PDMA side; dma-buf and mlx5 follow separately. Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Changes in v13: - Read the Intel SPT PCH ACS Control dword at its nonstandard offset so Translation Blocking is honored on host routes, addressing the Sashiko review of patch 10. - Distinguished unreadable forwarding controls from missing forwarding and retained redirect advice when clearing controls restores a direct route, addressing the Sashiko review of patch 5. - Updated the directional routing documentation for shared ancestors. - Reused the ACS isolation-test mock setup - Link to v12: https://patch.msgid.link/20261103-fix-p2p-acs-v4-0-v12-0-912101f93517@nvidi… Changes in v12: - Rebaed to v7.4-rc1 - Link to v11: https://patch.msgid.link/20261013-fix-p2p-acs-v4-0-v11-0-72cf8c96e617@nvidi… Changes in v11: - Applied the client ATS policy in pci_p2pdma_distance_many() too, as local Sashiko pointed out. - Read the ATS Enable bit once per query, so the class and the ATS policy always agree. - Documented that pcim_p2pdma_set_ats_per_mapping() needs a successful pcim_p2pdma_init(). - The path diagnostics no longer read ACS Control or the bridge bus range, and they report a failed cache store. - Added a KUnit case for Direct Translated P2P without a redirect. - Clarified the Relaxed Ordering and diagnostics commit messages. - Honored device-specific ACS redirection, such as Zhaoxin Downstream Ports, in a new first patch with a KUnit case, as local Sashiko pointed out. Relaxed Ordering Completions are redirected at such a port too. - Clarified in the documentation that a quirk also redirects Relaxed Ordering Completions and that Translation Blocking applies only to upstream Requests, and labelled the ACS routing debug line with its class, as local Sashiko pointed out. - Treated ACS registers that read as all ones as unreadable, and named ports that a quirk redirects instead of suggesting pci=disable_acs_redir= for them, as local Sashiko pointed out. - Ignored ACS quirks of endpoints, which only describe traffic between their own functions. - Link to v10: https://patch.msgid.link/20261012-fix-p2p-acs-v4-0-v10-0-6ffe7b7a4517@nvidi… Changes in v10: - Fixed the Relaxed Ordering description: a Completion carries the attribute of its Request (PCIe r7.0 sec 2.2.9.1). - Used the PCIe terms Requester and Completer for TLPs, ACS and ports; client and provider remain for P2PDMA objects. - Rebased on pci/p2pdma, which includes the prerequisite P2PDMA fixes. - Added a topology example to the path divergence patch. - Removed a repeated sentence from the disable_acs_redir documentation. - Explained the path divergence in the documentation. - Link to v9: https://patch.msgid.link/20261001-fix-p2p-acs-v4-0-v9-0-1a8e0f50ddd9@nvidia… Changes in v9: - Removed dmabuf patches for now. - Removed mlx5 per-mapping ATS declaration for now; it comes back with the dmabuf patches. - Link to v8: https://patch.msgid.link/20260928-fix-p2p-acs-v4-0-v8-0-404453b9c435@nvidia… Changes in v8: - Added extra Reviewed-by from Logan. - Added patches to take care of ATS per-device vs. per-mapping option - Link to v7: https://patch.msgid.link/20260920-fix-p2p-acs-v4-0-v7-0-ca0828ab697c@nvidia… Changes in v7: - Removed "Document pdev->p2pdma lifetime rules" patch, it gives nothing after p2pmem fix. - Split dmabuf patch. - Tushar retested the series, so added his Tested-by. - Added Logan's ROB tags and fixed minor documentation issues pointed by him. - Link to v6: https://lore.kernel.org/all/20260914-fix-p2p-acs-v4-0-v6-0-5ef07ec9ef06@nvi… Changes in v6: - Changed DMABUF to use callbacks and not directly stored pointer. - Link to v5: https://patch.msgid.link/20260910-fix-p2p-acs-v4-0-v5-0-856087f63c0d@nvidia… Changes in v5: - Rebase on the posted fixes. - Dropped tags from changed patches. - Remove Egress Control Vector interpretation and coverage. - Keep enabled Egress Control conservative as a Request redirect. - Use pci_dbg()/dev_dbg() for diagnostics and drop the "debug" prefix. - Removed code comments from "Document the pdev->p2pdma lifetime and RCU rules" patch and reduced description to actual lifetime explanation. - Added note that Linux assumes that TLPs are in strict-ordering and untranslated. - Added code to calculate p2p paths per-TLP type. - Converted mlx5 to use that new proposed API. - Link to https://patch.msgid.link/20260821-fix-p2p-acs-v4-0-v4-0-94426b96de73@nvidia… Changes in v4: - Reject ACS Violations and unreadable routing state instead of treating them as host-bridge redirects - Added Tested-by tags from Tushar Dave - Added support to asymmetric ACS routing - Limited redirect checks to the two ports at the path divergence - Added standalone ACS routing diagnostics for hardware retesting - Dropped " PCI: Account for Direct Translated P2P in ACS isolation checks" patch - Link to v3: https://patch.msgid.link/20260811-fix-p2p-acs-v3-0-efc488ee7c03@nvidia.com Changes in v3: - Fixed pci_p2pdma_add_resource() error unwinding - Made pdev->p2pdma teardown wait unconditionally for RCU readers - Restricted pci_p2pmem_find_many() to pool-backed providers - Documented the pdev->p2pdma lifetime and RCU rules - Fixed calc_map_type_and_dist() handling of the verbose argument - Required the ACS port and target to share a bus before indexing the Egress Control Vector - Gave pci_acs_enabled() and pci_acs_path_enabled() a scope, so the ACS Direct Translated P2P rule no longer stops pci_enable_pasid() from enabling PASID - Dropped "Report ACS ports when the paths share no upstream bridge": the mapping type cannot change without a shared upstream bridge, so the pci=disable_acs_redir= hint was not actionable there and the ACS walk only cost config space reads - Folded the Request Redirect rule into pci_acs_rr_ineffective(), so pci_acs_flags_enabled() and the Intel SPT PCH quirk share one copy - Renamed pci_acs_egress_ctrl_set() to pci_acs_egress_ctrl_is_set(), it reads the bit rather than setting it - Reworded the blocked-path warning: ACS may also leave the direct route indeterminate rather than blocked - Added KUnit coverage for the shared-bus guard, a device with no ACS capability and an unreadable ACS Control register - Added the missing Fixes: tags, a second one on the pci_p2pdma_add_resource() unwinding fix (the dangling devres action dates to f58ef9d1d135) and one on the Egress Control isolation change - Link to v2: https://patch.msgid.link/20260806-fix-p2p-acs-v2-0-0cec14812965@nvidia.com Changes in v2: - Added Logan's ROB tags - Added commas in Documentation patch - Link to v1: https://patch.msgid.link/20260802-fix-p2p-acs-v1-0-a7c5eb64fff6@nvidia.com --- Leon Romanovsky (19): PCI/P2PDMA: Honor device-specific ACS redirection PCI/P2PDMA: Document the TLP attribute assumptions PCI/P2PDMA: Derive routing from directional ACS controls PCI: Reject unreadable ACS controls in isolation checks PCI/P2PDMA: Evaluate ACS controls at the path divergence PCI/P2PDMA: Document directional ACS routing PCI/P2PDMA: Collect the path's ACS controls before deciding PCI/P2PDMA: Answer routing per TLP class PCI/P2PDMA: Route Relaxed Ordering Completions directly PCI/P2PDMA: Reject Translated Requests blocked by Translation Blocking PCI/P2PDMA: Route Translated Requests under Direct Translated P2P PCI/P2PDMA: Log detailed ACS routing diagnostics PCI/P2PDMA: Add KUnit tests for the ACS routing decisions PCI/P2PDMA: Test the ACS P2P routing walk PCI: Add KUnit coverage for ACS isolation checks PCI/P2PDMA: Document TLP-class routing PCI/P2PDMA: Let a client declare that it selects ATS per mapping PCI/P2PDMA: Evaluate the ATS path for clients with ATS enabled PCI/P2PDMA: Test the routing of clients with ATS enabled Documentation/admin-guide/kernel-parameters.txt | 11 +- Documentation/driver-api/pci/p2pdma.rst | 106 ++ drivers/pci/Kconfig | 15 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 961 ++++++++++++++-- drivers/pci/pci.c | 8 +- drivers/pci/pci.h | 63 + drivers/pci/pci_acs_test.c | 1409 +++++++++++++++++++++++ drivers/pci/quirks.c | 23 +- include/linux/pci-p2pdma.h | 12 +- 10 files changed, 2517 insertions(+), 92 deletions(-) --- base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4 change-id: 20260821-fix-p2p-acs-v4-0-e72455e3a261 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

7 hours, 25 minutes

[PATCH v8 0/9] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi all, The goal of this series is to enable userspace driver designs that use VFIO to export DMABUFs representing subsets of PCI device BARs, and "vend" those buffers from a primary process to other subordinate processes by fd. This is achieved by allowing the processes to mmap() the DMABUFs; their access to the device is isolated to the exported ranges. The primary userspace driver process can forcibly revoke access to previously-shared buffers upon cleanup (without requiring cooperation from the subordinate processes). This is an improvement on sharing the VFIO device fd to subordinate processes, which would allow unfettered access. See the RFCs for background. The existing VFIO PCI BAR mmap() becomes backed by a DMABUF too, keeping common vm_ops and fault handler for VMAs from the VFIO device and explicitly-exported DMABUFs. This will help future iommufd emulation of VFIO Type1 peer-to-peer, making it easier to get a DMABUF for a VFIO BAR as a DMA target. Below are per-patch notes & background info, and at the bottom are several related questions that reviewers may like to consider (worth at least skipping to #1, a possible bug). Notes on patches ================ mmap() conversion to use DMABUF underneath has been done for vfio-pci, but not sub-drivers: nvgrace-gpu's mmap() override path is unchanged; I kept this out of scope for now not least because I don't have a thorough test setup for this system. I would prefer to help the nvgrace-gpu maintainers enable BAR mmap() DMABUFs themselves. It's also worth noting that one reason for nvgrace-gpu's special BAR handling is to map RESMEM with a WC memory type. This is unchanged for existing mmap() but WC is not currently supported for mapping DMABUFs exported for that BAR; all DMABUF VMAs currently have the same memory type and control of UC/WC for a mapping is future work. vfio/pci: Remove DMABUF export dependency on vdev->memory_lock In v5 of this series we discover that doing an export from the VFIO mmap() path (fundamental!) adds a dependency between mmap_lock and vdev->memory_lock(W) because export was using memory_lock(W) to protect the vdev->dmabufs list and state within, and a deadlock scenario leapt out to bite: https://lore.kernel.org/kvm/9a615f22-c0d4-46ae-9654-db11e94e5fec@ozlabs.org/ The suggestion was to add a dedicated mutex/rwsem specifically for the DMABUFs/list, which is cleaner than overloading memory_lock(W). But whilst export could now downgrade to holding memory_lock(R) to test __vfio_pci_memory_enabled(), a very similar deadlock can still arise due to a memory_lock(W) elsewhere depending on a prior memory_lock(R) to be released, and attempting to take memory_lock(R) will queue behind the (W) for fairness (effectively an R->R dependency). I'd overlooked that rwsem cannot guarantee multiple readers. To be able to export while holding mmap_lock, export cannot hold memory_lock at all. Instead of testing __vfio_pci_memory_enabled() (which tracks PCI_COMMAND.MSE and PM state), this patch tracks device-global DMABUF revocation state in a new vdev->bars_revoked flag updated by vfio_pci_dma_buf_move(). If an mmap() is somehow performed during a period when DMABUFs are all revoked, then the DMABUF is created revoked. Move() already bookends reset, PM transitions etc., so subsequent revocation state changes work as-is. This flag is also protected by the dmabuf_lock and thus memory_lock is not required to export. vfio/pci: Un-revoke DMABUFs in LOW_POWER_ENTRY_WITH_WAKEUP resume On LOW_POWER entry, DMABUFs have a move(revoke=true), but the runtime resume path didn't un-revoke. This adds a corresponding move(revoke=false), which will later turn into vfio_pci_unrevoke_bars(). NOTE: the unrevoke is reordered _before_ the eventfd_signal() in vfio_pci_core_runtime_resume() to remove a window in which a waking waiter could have observed the DMABUF state as still revoked (or pm_runtime_engaged = true). (The UAPI docs state the event means the resume's complete, so observing otherwise seemed unintended.) Also, when DMABUFs are later mmap()ed, a waiter waking and taking a fault could have seen the unrevoked state and SIGBUS just before taking the memory_lock. (If the handler gets to acquire the lock, though, the resume sequence is complete, and the handler observes pm_runtime_engaged = false.) This fix is in this series because the issue will impact CPU access to the VMA as well (once they use DMABUFs), and so it's a strict dependency of later commits. dma-buf: Provide dma_buf_set_name() Makes dma_buf_set_name() available for use (by helper patch), taking a kernel-allocated string. The pre-existing local helper becomes a wrapper copying a __user string for the set-name ioctl. vfio/pci: Add a helper to look up PFNs for DMABUFs Adds a DMABUF VMA fault handler helper to determine arbitrary-sized PFNs from ranges in DMABUF. vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA Refactors DMABUF export for use by the existing export feature, and adds a helper that creates a DMABUF corresponding to a VFIO BAR mmap() request. There was a request for decent debug naming in /proc/<pid>/maps etc. comparable to the existing VFIO names: since the VMAs are DMABUFs, they have a "dmabuf:" prefix and can't be 100% identical to before. This is a user-visible change, but this patch at least now gives us extra info on the BDF & BAR being mmap()ed. The name is installed with the new dma_buf_set_name() above. vfio/pci: Convert BAR mmap() to use a DMABUF The vfio-pci core mmap() creates a DMABUF with the helper above, and the vm_ops fault handler uses the other helper to resolve the fault. Because this depends on DMABUF structs/code, CONFIG_VFIO_PCI_CORE needs to depend on CONFIG_DMA_SHARED_BUFFER. The CONFIG_VFIO_PCI_DMABUF still conditionally enables the export support code. NOTE: The user mmap()s a device fd, but the resulting VMA's vm_file becomes that of the DMABUF. The DMABUF takes ownership of the device file and put()s it on release, which maintains the existing behaviour of a VMA keeping the VFIO device open. BAR zapping then happens via the existing vfio_pci_dma_buf_move() path, which now needs to unmap PTEs in the DMABUF's address_space. NOTE: As local LLM reviews did, Sashiko might falsely worry about the DMABUF fd being obtained through /proc/pid/map_files and remapped, but the file is an anon inode and doesn't support the open op (-ENXIO) so AFAICT this is currently impossible. NOTE: A side-effect of this is that is_mergeable_vma() will be false between adjacent mappings of VFIO BARs; merging would require rebuilding a larger DMABUF representing the union, not just plugging the VMAs together. The DMABUF backing the BAR is an implicit/internal export, even when the CONFIG_VFIO_PCI_DMABUF feature is not included because CONFIG_PCI_P2PDMA is not available. Without P2PDMA, it's acceptable for the DMABUF to not have a P2PDMA provider. In this configuration, the VFIO DMABUF .attach prohibits any import, which avoids getting as far as a WARN in dma_buf_map_attachment(), which would fail without P2PDMA anyway. vfio/pci: Clean up BAR zap and revocation In general (see NOTE!) the vfio_pci_zap_bars() is now obsolete, since it unmaps PTEs in the VFIO device address_space which is now unused. This consolidates all calls (e.g. around reset) with the neighbouring vfio_pci_dma_buf_move()s into new functions, to revoke/unrevoke (making the steps clearer). NOTE: Because drivers can use their own vm_ops and override .mmap, the core must conservatively assume an overridden .mmap might still add PTEs to the VFIO device address_space and therefore still does the zap. A new flag, zap_bars_on_revoke, enables the zap when .mmap is overridden. A driver that does not need the zap can clear this to opt-out, e.g. if the driver calls down to the common mmap (and so uses DMABUFs). hisi-acc-vfio-pci does just this, and thus sets the opt-out flag. vfio/pci: Support mmap() of a VFIO DMABUF Adds mmap() for a DMABUF fd exported from vfio-pci. It was a goal to keep the VFIO device fd lifetime behaviour unchanged with respect to the DMABUFs. An application can close all device fds, and this will revoke/clean up all DMABUFs; then, no mappings or other access can be performed. When enabling mmap() of the DMABUFs, this means access through the VMA is also revoked. This complicates the fault handler because whilst the DMABUF exists, it has no guarantee that the corresponding VFIO device is still alive. Adds synchronisation ensuring the vdev is available before the locks in vdev are touched; this holds the device registration so that even if the buffer has been cleaned up, vdev hasn't been freed and so the locks can be safely taken. vfio/pci: Revoke a DMABUF on request from userspace This is mostly a rename of `revoked` to an enum, `status`, and adding a third state for a buffer: usable, revoked temporary, revoked permanent. A new VFIO feature is added, VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE, which takes a DMABUF (exported from the same device) and permanently revokes it. Thus a userspace driver can guarantee any downstream consumers of a shared fd are prevented from accessing a BAR range, and that range can be reused. NOTE: This might block userspace, waiting on importers to detach. The code doing revocation in vfio_pci_dma_buf_move() is moved, to a common function used by ..._move() and this new feature. Testing ======= (The [RFC ONLY] userspace test program, which drives a QEMU bochs-display function, can be found in the GitHub branch below. It at least illustrates how the export, map, revoke, and close semantics interoperate. WIP on a follow-up with a proper vfio-selftests style test based on this -- this won't be part of this series.) This code has been tested in mapping DMABUFs of single/multiple ranges from multiple BARs, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings. No regressions observed on the VFIO selftests, or on our internal vfio-pci applications. VFIO on i386 has been build-tested. Thanks to Alex Mastro for building a (WIP) testcase for the prior mmap_lock->memory_lock issue. END === This is based on v7.3-rc6 These commits are on GitHub for easier browsing, along with "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test": https://github.com/evansm7/linux/compare/v7.3-rc6...dev/mev/vfio-dmabuf-mma… Also please see... https://lore.kernel.org/all/f8efaabd-c06e-4f04-8cfa-489c148e37ba@ozlabs.org/ ("[PATCH] dma-buf: Annul dmabuf->file on file release") ...which fixes a stale file pointer issue that could affect VFIO's DMABUF export. Although the issue exists prior to this series, the addition of another dmabuf->file dereference adds additional unpleasant failure modes (for example, unmap_mapping_range() the wrong file, or good old random data dereference, etc.) Thanks for reading, Matt ================================================================================ Changelog: v8: - Rebased, on v7.3-rc6 - "dma-buf: Provide dma_buf_set_name()": Comment and "DOC: locking convention" updates. dma_buf_set_name() is is listed in the "do not hold resv" category v7: https://lore.kernel.org/all/20260924152159.49702-1-matt@ozlabs.org/ v6: https://lore.kernel.org/all/20260911214200.33793-1-matt@ozlabs.org/ v5: https://lore.kernel.org/all/20260715174737.15287-1-matt@ozlabs.org/ v4: https://lore.kernel.org/all/20260701171245.90111-1-matt@ozlabs.org/ v3: https://lore.kernel.org/all/20260610154327.37758-1-matt@ozlabs.org/ v2: https://lore.kernel.org/all/20260527102319.100128-1-mattev@meta.com/ v1: https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/ RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ Matt Evans (9): vfio/pci: Remove DMABUF export dependency on vdev->memory_lock vfio/pci: Un-revoke DMABUFs in LOW_POWER_ENTRY_WITH_WAKEUP resume dma-buf: Provide dma_buf_set_name() vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA vfio/pci: Convert BAR mmap() to use a DMABUF vfio/pci: Clean up BAR zap and revocation vfio/pci: Support mmap() of a VFIO DMABUF vfio/pci: Revoke a DMABUF on request from userspace drivers/dma-buf/dma-buf.c | 84 ++- drivers/vfio/pci/Kconfig | 4 +- drivers/vfio/pci/Makefile | 3 +- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 14 +- drivers/vfio/pci/vfio_pci_config.c | 30 +- drivers/vfio/pci/vfio_pci_core.c | 222 +++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 609 +++++++++++++++--- drivers/vfio/pci/vfio_pci_priv.h | 54 +- include/linux/dma-buf.h | 16 +- include/linux/vfio_pci_core.h | 3 + include/uapi/linux/vfio.h | 24 + 11 files changed, 870 insertions(+), 193 deletions(-) -- 2.47.3

8 hours, 53 minutes

Re: [PATCH] bpf: make dmabuf iterator stay drained after NULL

by Christian König

Adding T.J. to comment. Regards, Christian. On 11/10/26 13:51, Kang Chen wrote: > bpf_iter_dmabuf_next() uses kit->dmabuf == NULL to mean "iteration has > not started". dma_buf_iter_next() also returns NULL at the end of the > list, so a next() call after exhaustion restarts from the list head. > > The verifier relies on the iterator contract that once next() returns > NULL it keeps returning NULL: process_iter_next_call() marks the > iterator DRAINED and treats the result of later next() calls as the > constant zero. A restarted dmabuf iteration therefore hands the BPF > program a kernel pointer while the verifier believes R0 == 0. > > Use an invalid pointer value as the drained sentinel so the iterator > state keeps its one-pointer ABI, and skip dma_buf_put() for it. > > Fixes: 6eab7ac7c5ee ("bpf: Add open coded dmabuf iterator") > Signed-off-by: Kang Chen <k.chen(a)smail.nju.edu.cn> > --- > kernel/bpf/dmabuf_iter.c | 23 ++++++++++++++++++++++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/kernel/bpf/dmabuf_iter.c b/kernel/bpf/dmabuf_iter.c > index cd500248abd9..a2b7c38f9ae6 100644 > --- a/kernel/bpf/dmabuf_iter.c > +++ b/kernel/bpf/dmabuf_iter.c > @@ -156,6 +156,13 @@ struct bpf_iter_dmabuf_kern { > struct dma_buf *dmabuf; > } __aligned(8); > > +/* > + * The iterator state is one pointer wide because struct bpf_iter_dmabuf is > + * part of the generated vmlinux.h ABI. Use an invalid pointer value as the > + * "drained" sentinel instead of growing the state. > + */ > +#define DMABUF_ITER_DONE ((struct dma_buf *)1L) > + > __bpf_kfunc_start_defs(); > > __bpf_kfunc int bpf_iter_dmabuf_new(struct bpf_iter_dmabuf *it) > @@ -173,11 +180,25 @@ __bpf_kfunc struct dma_buf *bpf_iter_dmabuf_next(struct bpf_iter_dmabuf *it) > { > struct bpf_iter_dmabuf_kern *kit = (void *)it; > > + /* > + * The verifier assumes that an iterator which returned NULL keeps > + * returning NULL (see process_iter_next_call()). Without this check > + * the NULL left by the last dma_buf_iter_next() would be interpreted > + * as "not started" and the iteration would restart from the list head. > + */ > + if (kit->dmabuf == DMABUF_ITER_DONE) > + return NULL; > + > if (kit->dmabuf) > kit->dmabuf = dma_buf_iter_next(kit->dmabuf); > else > kit->dmabuf = dma_buf_iter_begin(); > > + if (!kit->dmabuf) { > + kit->dmabuf = DMABUF_ITER_DONE; > + return NULL; > + } > + > return kit->dmabuf; > } > > @@ -185,7 +206,7 @@ __bpf_kfunc void bpf_iter_dmabuf_destroy(struct bpf_iter_dmabuf *it) > { > struct bpf_iter_dmabuf_kern *kit = (void *)it; > > - if (kit->dmabuf) > + if (kit->dmabuf && kit->dmabuf != DMABUF_ITER_DONE) > dma_buf_put(kit->dmabuf); > } > > -- > 2.34.1 >

11 hours, 23 minutes

[PATCH V3] accel/amdxdna: Drop dma-buf wrapping for ubuf

by Lizhi Hou

A ubuf buffer is a range of existing userspace memory passed in through CREATE_BO. The driver currently wraps those pages in a dma-buf, then imports that dma-buf as a GEM object. The extra layer does not add a sharing path: ubuf is not exportable, and the pages never belonged to the driver in the first place. Make ubuf a DRM GEM private object and tracks the user VA with HMM instead of a long-term pin. - Create the BO directly from the VA table without going through dma-buf. Export stays unsupported. - Drop pin_user_pages(FOLL_LONGTERM). Create registers an MMU interval notifier over the user range and marks it invalid. Command submit faults the range in if it is still invalid. That only works with PASID, which is the only mode where ubuf is supported. Signed-off-by: Lizhi Hou <lizhi.hou(a)amd.com> --- V3: Sync to the latest code. V2: Fix sashiko comment: remove holding process's virtual address space. drivers/accel/amdxdna/amdxdna_gem.c | 70 ++++----- drivers/accel/amdxdna/amdxdna_gem.h | 10 ++ drivers/accel/amdxdna/amdxdna_ubuf.c | 207 ++++++++++----------------- drivers/accel/amdxdna/amdxdna_ubuf.h | 8 +- 4 files changed, 128 insertions(+), 167 deletions(-) diff --git a/drivers/accel/amdxdna/amdxdna_gem.c b/drivers/accel/amdxdna/amdxdna_gem.c index ffe12a722dfea..a94195ea4e045 100644 --- a/drivers/accel/amdxdna/amdxdna_gem.c +++ b/drivers/accel/amdxdna/amdxdna_gem.c @@ -165,8 +165,7 @@ void amdxdna_gem_heap_free(struct amdxdna_client *client, struct amdxdna_gem_obj mutex_unlock(&client->mm_lock); } -static void -amdxdna_gem_destroy_obj(struct amdxdna_gem_obj *abo) +void amdxdna_gem_destroy_obj(struct amdxdna_gem_obj *abo) { mutex_destroy(&abo->lock); kfree(abo); @@ -191,7 +190,9 @@ void *amdxdna_gem_vmap(struct amdxdna_gem_obj *abo) if (!abo->mem.kva) { ret = drm_gem_vmap(to_gobj(abo), &map); - if (ret) + if (ret == -EOPNOTSUPP) + XDNA_DBG(xdna, "Vmap bo is not supported"); + else if (ret) XDNA_ERR(xdna, "Vmap bo failed, ret %d", ret); else abo->mem.kva = map.vaddr; @@ -331,7 +332,7 @@ static void amdxdna_umap_put(struct amdxdna_umap *mapp) kref_put(&mapp->refcnt, amdxdna_umap_release); } -static void amdxdna_hmm_unreg_umaps(struct amdxdna_gem_obj *abo, bool force) +void amdxdna_hmm_unreg_umaps(struct amdxdna_gem_obj *abo, bool force) { struct amdxdna_dev *xdna = to_xdna_dev(to_gobj(abo)->dev); struct amdxdna_umap *mapp, *tmp; @@ -452,12 +453,11 @@ bool amdxdna_gem_umap_stale(struct amdxdna_gem_obj *abo) return false; } -static int amdxdna_hmm_register(struct amdxdna_gem_obj *abo, - struct vm_area_struct *vma) +int amdxdna_hmm_register(struct amdxdna_gem_obj *abo, struct vm_area_struct *vma, + size_t offset, size_t len) { struct amdxdna_dev *xdna = to_xdna_dev(to_gobj(abo)->dev); - unsigned long len = vma->vm_end - vma->vm_start; - unsigned long addr = vma->vm_start; + unsigned long addr = vma->vm_start + offset; struct amdxdna_umap *mapp; int ret; @@ -524,7 +524,7 @@ static int amdxdna_hmm_register(struct amdxdna_gem_obj *abo, return 0; } -static struct amdxdna_gem_obj * +struct amdxdna_gem_obj * amdxdna_gem_create_obj(struct drm_device *dev, size_t size) { struct amdxdna_gem_obj *abo; @@ -569,7 +569,7 @@ static void amdxdna_gem_dev_obj_free(struct drm_gem_object *gobj) amdxdna_gem_destroy_obj(abo); } -static void amdxdna_mark_map_invalid(struct amdxdna_gem_obj *abo) +void amdxdna_mark_map_invalid(struct amdxdna_gem_obj *abo) { struct amdxdna_dev *xdna = to_xdna_dev(to_gobj(abo)->dev); @@ -678,7 +678,7 @@ static int amdxdna_gem_obj_mmap(struct drm_gem_object *gobj, drm_vma_node_offset_addr(&gobj->vma_node), abo->type, vma->vm_start, gobj->size); - ret = amdxdna_hmm_register(abo, vma); + ret = amdxdna_hmm_register(abo, vma, 0, vma->vm_end - vma->vm_start); if (ret) return ret; @@ -748,7 +748,7 @@ static struct dma_buf *amdxdna_gem_prime_export(struct drm_gem_object *gobj, int struct amdxdna_gem_obj *abo = to_xdna_obj(gobj); DEFINE_DMA_BUF_EXPORT_INFO(exp_info); - if (abo->private_buffer) + if (is_private_bo(abo)) return ERR_PTR(-EOPNOTSUPP); if (abo->dma_buf) { @@ -832,7 +832,7 @@ static void amdxdna_gem_obj_free(struct drm_gem_object *gobj) drm_gem_shmem_free(&abo->base); } -static int amdxdna_gem_obj_open(struct drm_gem_object *gobj, struct drm_file *filp) +int amdxdna_gem_obj_open(struct drm_gem_object *gobj, struct drm_file *filp) { struct amdxdna_dev *xdna = to_xdna_dev(gobj->dev); struct amdxdna_gem_obj *abo = to_xdna_obj(gobj); @@ -871,7 +871,7 @@ static int amdxdna_gem_obj_open(struct drm_gem_object *gobj, struct drm_file *fi return 0; } -static void amdxdna_gem_obj_close(struct drm_gem_object *gobj, struct drm_file *filp) +void amdxdna_gem_obj_close(struct drm_gem_object *gobj, struct drm_file *filp) { struct amdxdna_gem_obj *abo = to_xdna_obj(gobj); struct amdxdna_client *client = NULL; @@ -1057,40 +1057,46 @@ amdxdna_gem_create_shmem_object(struct drm_device *dev, struct amdxdna_drm_creat } static struct amdxdna_gem_obj * -amdxdna_gem_create_ubuf_object(struct drm_device *dev, struct amdxdna_drm_create_bo *args) +amdxdna_gem_create_ubuf_object(struct drm_device *dev, + struct amdxdna_drm_create_bo *args, + struct drm_file *filp) { + struct amdxdna_client *client = filp->driver_priv; struct amdxdna_dev *xdna = to_xdna_dev(dev); struct amdxdna_drm_va_tbl va_tbl; struct amdxdna_gem_obj *abo; struct drm_gem_object *gobj; struct dma_buf *dma_buf; + if (args->type == AMDXDNA_BO_DEV_HEAP || args->type == AMDXDNA_BO_CMD) + return ERR_PTR(-EOPNOTSUPP); + if (copy_from_user(&va_tbl, u64_to_user_ptr(args->vaddr), sizeof(va_tbl))) { XDNA_DBG(xdna, "Access va table failed"); return ERR_PTR(-EINVAL); } if (va_tbl.num_entries) { - dma_buf = amdxdna_get_ubuf(dev, va_tbl.num_entries, - u64_to_user_ptr(args->vaddr + sizeof(va_tbl))); + abo = amdxdna_alloc_ubuf_bo(client, va_tbl.num_entries, + u64_to_user_ptr(args->vaddr + sizeof(va_tbl))); + if (IS_ERR(abo)) + return abo; + abo->private_buffer = true; } else { dma_buf = dma_buf_get(va_tbl.dmabuf_fd); - } + if (IS_ERR(dma_buf)) + return ERR_CAST(dma_buf); - if (IS_ERR(dma_buf)) - return ERR_CAST(dma_buf); + gobj = amdxdna_gem_prime_import(dev, dma_buf); + if (IS_ERR(gobj)) { + dma_buf_put(dma_buf); + return ERR_CAST(gobj); + } - gobj = amdxdna_gem_prime_import(dev, dma_buf); - if (IS_ERR(gobj)) { dma_buf_put(dma_buf); - return ERR_CAST(gobj); + abo = to_xdna_obj(gobj); } - dma_buf_put(dma_buf); - - abo = to_xdna_obj(gobj); - abo->private_buffer = true; - return abo; } @@ -1178,7 +1184,7 @@ amdxdna_drm_create_share_bo(struct drm_device *dev, struct amdxdna_gem_obj *abo; if (args->vaddr) - abo = amdxdna_gem_create_ubuf_object(dev, args); + abo = amdxdna_gem_create_ubuf_object(dev, args, filp); else if (amdxdna_use_carveout(to_xdna_dev(dev))) abo = amdxdna_gem_create_cbuf_object(dev, args); else @@ -1364,7 +1370,7 @@ static int amdxdna_bo_pin(struct amdxdna_gem_obj *abo) struct amdxdna_dev *xdna = to_xdna_dev(to_gobj(abo)->dev); int ret; - if (is_import_bo(abo)) + if (is_import_bo(abo) || is_private_bo(abo)) return 0; ret = drm_gem_shmem_pin(&abo->base); @@ -1377,7 +1383,7 @@ static void amdxdna_bo_unpin(struct amdxdna_gem_obj *abo) { struct amdxdna_dev *xdna = to_xdna_dev(to_gobj(abo)->dev); - if (is_import_bo(abo)) + if (is_import_bo(abo) || is_private_bo(abo)) return; drm_gem_shmem_unpin(&abo->base); @@ -1477,7 +1483,7 @@ int amdxdna_drm_get_bo_info_ioctl(struct drm_device *dev, void *data, struct drm args->vaddr = amdxdna_gem_uva(abo); args->xdna_addr = amdxdna_gem_dev_addr(abo); - if (abo->type != AMDXDNA_BO_DEV) + if (abo->type != AMDXDNA_BO_DEV && !is_private_bo(abo)) args->map_offset = drm_vma_node_offset_addr(&gobj->vma_node); else args->map_offset = AMDXDNA_INVALID_ADDR; diff --git a/drivers/accel/amdxdna/amdxdna_gem.h b/drivers/accel/amdxdna/amdxdna_gem.h index 2deead107d6b1..b55c5f11cbb18 100644 --- a/drivers/accel/amdxdna/amdxdna_gem.h +++ b/drivers/accel/amdxdna/amdxdna_gem.h @@ -67,6 +67,7 @@ struct amdxdna_gem_obj { #define to_gobj(obj) (&(obj)->base.base) #define is_import_bo(obj) ((obj)->attach) +#define is_private_bo(obj) ((obj)->private_buffer) static inline struct amdxdna_gem_obj *to_xdna_obj(struct drm_gem_object *gobj) { @@ -121,10 +122,19 @@ amdxdna_gem_prime_import(struct drm_device *dev, struct dma_buf *dma_buf); struct amdxdna_gem_obj * amdxdna_drm_create_dev_bo(struct drm_device *dev, struct amdxdna_drm_create_bo *args, struct drm_file *filp); +struct amdxdna_gem_obj * +amdxdna_gem_create_obj(struct drm_device *dev, size_t size); +void amdxdna_gem_destroy_obj(struct amdxdna_gem_obj *abo); +void amdxdna_hmm_unreg_umaps(struct amdxdna_gem_obj *abo, bool force); int amdxdna_gem_pin_nolock(struct amdxdna_gem_obj *abo); int amdxdna_gem_pin(struct amdxdna_gem_obj *abo); void amdxdna_gem_unpin(struct amdxdna_gem_obj *abo); +int amdxdna_gem_obj_open(struct drm_gem_object *gobj, struct drm_file *filp); +void amdxdna_gem_obj_close(struct drm_gem_object *gobj, struct drm_file *filp); +int amdxdna_hmm_register(struct amdxdna_gem_obj *abo, struct vm_area_struct *vma, + size_t offset, size_t len); +void amdxdna_mark_map_invalid(struct amdxdna_gem_obj *abo); int amdxdna_drm_create_bo_ioctl(struct drm_device *dev, void *data, struct drm_file *filp); int amdxdna_drm_get_bo_info_ioctl(struct drm_device *dev, void *data, struct drm_file *filp); diff --git a/drivers/accel/amdxdna/amdxdna_ubuf.c b/drivers/accel/amdxdna/amdxdna_ubuf.c index 0e0cd69cd1fbf..a5e202fbc72b9 100644 --- a/drivers/accel/amdxdna/amdxdna_ubuf.c +++ b/drivers/accel/amdxdna/amdxdna_ubuf.c @@ -6,182 +6,127 @@ #include <drm/amdxdna_accel.h> #include <drm/drm_device.h> #include <drm/drm_print.h> -#include <linux/dma-buf.h> #include <linux/overflow.h> #include <linux/pagemap.h> #include <linux/vmalloc.h> +#include "amdxdna_gem.h" #include "amdxdna_pci_drv.h" #include "amdxdna_ubuf.h" -struct amdxdna_ubuf_priv { - struct page **pages; - u64 nr_pages; - struct mm_struct *mm; -}; - -static struct sg_table *amdxdna_ubuf_map(struct dma_buf_attachment *attach, - enum dma_data_direction direction) +static int amdxdna_ubuf_hmm_register(struct amdxdna_client *client, + struct amdxdna_gem_obj *abo, + struct amdxdna_drm_va_entry *va_ent) { - struct amdxdna_ubuf_priv *ubuf = attach->dmabuf->priv; - struct sg_table *sg; + struct vm_area_struct *vma; int ret; - sg = kzalloc_obj(*sg); - if (!sg) - return ERR_PTR(-ENOMEM); - - ret = sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->nr_pages, 0, - ubuf->nr_pages << PAGE_SHIFT, GFP_KERNEL); - if (ret) - goto err_free_sg; + mmap_write_lock(client->mm); + vma = find_vma(client->mm, va_ent->vaddr); + if (!vma || vma->vm_start > va_ent->vaddr || + vma->vm_end - va_ent->vaddr < va_ent->len) { + ret = -EINVAL; + goto unlock; + } - ret = dma_map_sgtable(attach->dev, sg, direction, 0); - if (ret) - goto err_free_table; + ret = amdxdna_hmm_register(abo, vma, va_ent->vaddr - vma->vm_start, va_ent->len); + if (!ret && !(vma->vm_flags & (VM_PFNMAP | VM_IO))) + amdxdna_mark_map_invalid(abo); - return sg; +unlock: + mmap_write_unlock(client->mm); -err_free_table: - sg_free_table(sg); -err_free_sg: - kfree(sg); - return ERR_PTR(ret); + return ret; } -static void amdxdna_ubuf_unmap(struct dma_buf_attachment *attach, - struct sg_table *sg, - enum dma_data_direction direction) +static void amdxdna_gem_ubuf_obj_free(struct drm_gem_object *gobj) { - dma_unmap_sgtable(attach->dev, sg, direction, 0); - sg_free_table(sg); - kfree(sg); + struct amdxdna_gem_obj *abo = to_xdna_obj(gobj); + + amdxdna_hmm_unreg_umaps(abo, true); + cancel_work_sync(&abo->hmm_unreg_work); + + drm_gem_object_release(gobj); + amdxdna_gem_destroy_obj(abo); } -static void amdxdna_ubuf_release(struct dma_buf *dbuf) +static struct dma_buf *amdxdna_gem_ubuf_obj_export(struct drm_gem_object *gobj, int flags) { - struct amdxdna_ubuf_priv *ubuf = dbuf->priv; - - unpin_user_pages(ubuf->pages, ubuf->nr_pages); - kvfree(ubuf->pages); - atomic64_sub(ubuf->nr_pages, &ubuf->mm->pinned_vm); - mmdrop(ubuf->mm); - kfree(ubuf); + return ERR_PTR(-EOPNOTSUPP); } -static const struct dma_buf_ops amdxdna_ubuf_dmabuf_ops = { - .map_dma_buf = amdxdna_ubuf_map, - .unmap_dma_buf = amdxdna_ubuf_unmap, - .release = amdxdna_ubuf_release, +static const struct drm_gem_object_funcs amdxdna_gem_ubuf_obj_funcs = { + .free = amdxdna_gem_ubuf_obj_free, + .open = amdxdna_gem_obj_open, + .close = amdxdna_gem_obj_close, + .export = amdxdna_gem_ubuf_obj_export, }; -struct dma_buf *amdxdna_get_ubuf(struct drm_device *dev, - u32 num_entries, void __user *va_entries) +struct amdxdna_gem_obj *amdxdna_alloc_ubuf_bo(struct amdxdna_client *client, + u32 num_entries, void __user *va_entries) { - struct amdxdna_dev *xdna = to_xdna_dev(dev); - unsigned long lock_limit, new_pinned; + struct amdxdna_dev *xdna = client->xdna; struct amdxdna_drm_va_entry *va_ent; - struct amdxdna_ubuf_priv *ubuf; - u32 npages, start = 0; - struct dma_buf *dbuf; - int i, ret; - DEFINE_DMA_BUF_EXPORT_INFO(exp_info); + struct amdxdna_gem_obj *abo; + size_t bufsize; + long ret; - if (!can_do_mlock()) - return ERR_PTR(-EPERM); + if (!amdxdna_pasid_on(client)) + return ERR_PTR(-EOPNOTSUPP); - ubuf = kzalloc_obj(*ubuf); - if (!ubuf) - return ERR_PTR(-ENOMEM); + /* + * There is not any valid case to use more than 1 entry. + * Hardcode maximum entries to 1. + */ + if (num_entries > 1) + return ERR_PTR(-EINVAL); - ubuf->mm = current->mm; - mmgrab(ubuf->mm); + if (current->mm != client->mm) + return ERR_PTR(-EINVAL); - va_ent = kvzalloc_objs(*va_ent, num_entries); - if (!va_ent) { - ret = -ENOMEM; - goto free_ubuf; - } + va_ent = kvzalloc_obj(*va_ent); + if (!va_ent) + return ERR_PTR(-ENOMEM); - if (copy_from_user(va_ent, va_entries, sizeof(*va_ent) * num_entries)) { + if (copy_from_user(va_ent, va_entries, sizeof(*va_ent))) { XDNA_DBG(xdna, "Access va entries failed"); ret = -EINVAL; goto free_ent; } - for (i = 0, exp_info.size = 0; i < num_entries; i++) { - if (!IS_ALIGNED(va_ent[i].vaddr, PAGE_SIZE) || - !IS_ALIGNED(va_ent[i].len, PAGE_SIZE)) { - XDNA_ERR(xdna, "Invalid address or len %llx, %llx", - va_ent[i].vaddr, va_ent[i].len); - ret = -EINVAL; - goto free_ent; - } - - if (check_add_overflow(exp_info.size, va_ent[i].len, &exp_info.size)) { - ret = -EINVAL; - goto free_ent; - } - } - - ubuf->nr_pages = exp_info.size >> PAGE_SHIFT; - lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT; - new_pinned = atomic64_add_return(ubuf->nr_pages, &ubuf->mm->pinned_vm); - if (new_pinned > lock_limit && !capable(CAP_IPC_LOCK)) { - XDNA_DBG(xdna, "New pin %ld, limit %ld, cap %d", - new_pinned, lock_limit, capable(CAP_IPC_LOCK)); - ret = -ENOMEM; - goto sub_pin_cnt; + if (!IS_ALIGNED(va_ent->vaddr, PAGE_SIZE) || + !IS_ALIGNED(va_ent->len, PAGE_SIZE) || + !va_ent->len || + check_add_overflow(va_ent->vaddr, va_ent->len, &bufsize)) { + XDNA_DBG(xdna, "Invalid address or len %llx, %llx", + va_ent->vaddr, va_ent->len); + ret = -EINVAL; + goto free_ent; } - ubuf->pages = kvmalloc_objs(*ubuf->pages, ubuf->nr_pages); - if (!ubuf->pages) { - ret = -ENOMEM; - goto sub_pin_cnt; + bufsize = va_ent->len; + abo = amdxdna_gem_create_obj(&xdna->ddev, bufsize); + if (IS_ERR(abo)) { + ret = PTR_ERR(abo); + goto free_ent; } - for (i = 0; i < num_entries; i++) { - npages = va_ent[i].len >> PAGE_SHIFT; - - ret = pin_user_pages_fast(va_ent[i].vaddr, npages, - FOLL_WRITE | FOLL_LONGTERM, - &ubuf->pages[start]); - if (ret >= 0) { - start += ret; - if (ret != npages) { - XDNA_ERR(xdna, "Partially pinned pages %d/%u", ret, npages); - ret = -ENOMEM; - goto destroy_pages; - } - } else { - XDNA_ERR(xdna, "Failed to pin pages ret %d", ret); - goto destroy_pages; - } - } + abo->type = AMDXDNA_BO_SHARE; + abo->mem.uva = va_ent->vaddr; + to_gobj(abo)->funcs = &amdxdna_gem_ubuf_obj_funcs; + drm_gem_private_object_init(&xdna->ddev, to_gobj(abo), bufsize); - exp_info.ops = &amdxdna_ubuf_dmabuf_ops; - exp_info.priv = ubuf; - exp_info.flags = O_RDWR | O_CLOEXEC; + ret = amdxdna_ubuf_hmm_register(client, abo, va_ent); + if (ret) + goto put_obj; - dbuf = dma_buf_export(&exp_info); - if (IS_ERR(dbuf)) { - ret = PTR_ERR(dbuf); - goto destroy_pages; - } kvfree(va_ent); - return dbuf; + return abo; -destroy_pages: - if (start) - unpin_user_pages(ubuf->pages, start); - kvfree(ubuf->pages); -sub_pin_cnt: - atomic64_sub(ubuf->nr_pages, &ubuf->mm->pinned_vm); +put_obj: + drm_gem_object_put(to_gobj(abo)); free_ent: kvfree(va_ent); -free_ubuf: - mmdrop(ubuf->mm); - kfree(ubuf); return ERR_PTR(ret); } diff --git a/drivers/accel/amdxdna/amdxdna_ubuf.h b/drivers/accel/amdxdna/amdxdna_ubuf.h index 8900a6dc4371b..f6335603da348 100644 --- a/drivers/accel/amdxdna/amdxdna_ubuf.h +++ b/drivers/accel/amdxdna/amdxdna_ubuf.h @@ -5,10 +5,10 @@ #ifndef _AMDXDNA_UBUF_H_ #define _AMDXDNA_UBUF_H_ -#include <drm/drm_device.h> -#include <linux/dma-buf.h> +#include "amdxdna_gem.h" +#include "amdxdna_pci_drv.h" -struct dma_buf *amdxdna_get_ubuf(struct drm_device *dev, - u32 num_entries, void __user *va_entries); +struct amdxdna_gem_obj *amdxdna_alloc_ubuf_bo(struct amdxdna_client *client, + u32 num_entries, void __user *va_entries); #endif /* _AMDXDNA_UBUF_H_ */ base-commit: 41b5458595c60143d0ebaa1e032c9cda5d764dff -- 2.34.1

23 hours, 15 minutes

Re: [PATCH 2/7] dma-buf/udmabuf: account the page array metadata to memcg

by Christian König

On 11/6/26 14:18, Tao Cui wrote: > From: Tao Cui <cuitao(a)kylinos.cn> > > udmabuf pins the pages of a memfd and hands them out as a dma-buf. The > data pages keep the accounting of the memfd they were instantiated in, > but the bookkeeping around them does not: the page pointer array and > the pinned_folios array, both sized by the buffer page count, plus the > transient folios array sized by the memfd folio count, are plain > GFP_KERNEL. A 1GB buffer costs about 4MB of uncharged SUnreclaim > memory, and size_limit_mb defaults to INT_MAX. > > Charge the three kvmalloc allocations so the creator pays for the > metadata it induces. The system heap in the same subsystem already > accounts its buffer allocation; the data pages here stay with the > memfd. T.J. needs to take a look here, but I fear that this might break uAPI. A lot of the DMA-buf resources are intentionally not charged against memcg. Regards, Christian. > > Signed-off-by: Tao Cui <cuitao(a)kylinos.cn> > --- > drivers/dma-buf/udmabuf.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index df6dd0046242..40182c82df6b 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -190,11 +190,12 @@ static void unpin_all_folios(struct udmabuf *ubuf) > > static __always_inline int init_udmabuf(struct udmabuf *ubuf, pgoff_t pgcnt) > { > - ubuf->pages = kvmalloc_objs(*ubuf->pages, pgcnt); > + ubuf->pages = kvmalloc_objs(*ubuf->pages, pgcnt, GFP_KERNEL_ACCOUNT); > if (!ubuf->pages) > return -ENOMEM; > > - ubuf->pinned_folios = kvmalloc_objs(*ubuf->pinned_folios, pgcnt); > + ubuf->pinned_folios = kvmalloc_objs(*ubuf->pinned_folios, pgcnt, > + GFP_KERNEL_ACCOUNT); > if (!ubuf->pinned_folios) > return -ENOMEM; > > @@ -387,7 +388,7 @@ static long udmabuf_create(struct miscdevice *device, > if (ret) > goto err; > > - folios = kvmalloc_objs(*folios, max_nr_folios); > + folios = kvmalloc_objs(*folios, max_nr_folios, GFP_KERNEL_ACCOUNT); > if (!folios) { > ret = -ENOMEM; > goto err; > -- > 2.43.0 >

2 days, 5 hours

Re: [PATCH 1/3] dt-bindings: i2c: ti,omap4-i2c: Add DMA properties

by Krzysztof Kozlowski

On Thu, Nov 05, 2026 at 09:05:52PM +0100, Antoni Pokusinski wrote: > Document the TX and RX DMA request channels featured > by the OMAP I2C controller. > > Signed-off-by: Antoni Pokusinski <apokusinski01(a)gmail.com> > --- > .../devicetree/bindings/i2c/ti,omap4-i2c.yaml | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml > index 58d32ceeacfc..ff946fdfaad3 100644 > --- a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml > +++ b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml > @@ -37,6 +37,16 @@ properties: > clock-names: > const: fck > > + dmas: > + items: > + - description: TX DMA channel phandle > + - description: RX DMA channel phandle > + > + dma-names: > + items: > + - const: tx > + - const: rx Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)oss.qualcomm.com> Best regards, Krzysztof

2 days, 6 hours

[PATCH] kselftests: dmabuf-heaps: Open heap device files O_RDONLY

by T.J. Mercier

Write permissions on the /dev/dma_heap/* device files are not required to issue ioctls and allocate dmabufs. Applications should be opening these file as O_RDONLY. The BPF dmabuf_iter selftest already does this. [1] Users are pointing to these selftests as examples of how use dmabuf, and encountering permission errors on systems where write permissions are not available on /dev/dma_heap/*. Apply the principle of least privilege to selftests which open dmabuf heaps by removing the write access mode and using O_RDONLY for the open() instead. The same is true for the vgem test using /dev/dri/card. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/too… Signed-off-by: T.J. Mercier <tjmercier(a)google.com> --- tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c index fc9694fc4e89..45b420e37c97 100644 --- a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c @@ -48,7 +48,7 @@ static int open_vgem(void) snprintf(name, 80, "%s%u", drmstr, i); - fd = open(name, O_RDWR); + fd = open(name, O_RDONLY); if (fd < 0) continue; @@ -96,7 +96,7 @@ static int dmabuf_heap_open(char *name) if (ret < 0) ksft_exit_fail_msg("snprintf failed! %d\n", ret); - fd = open(buf, O_RDWR); + fd = open(buf, O_RDONLY); if (fd < 0) ksft_exit_fail_msg("open %s failed: %s\n", buf, strerror(errno)); base-commit: 9a11db68872055e6ead919bad04d6330851c522d -- 2.55.0.679.g6767b8d81c-goog

2 days, 8 hours

Re: [PATCH v2 06/23] dma-buf: Let the exporter select mapping type at pin/map

by Christian König

On 11/9/26 03:58, Alistair Popple wrote: > On 2026-11-07 at 19:57 +1100, Karl Mehltretter <kmehltretter(a)gmail.com> wrote... >> On Thu, Nov 05, 2026 at 05:40:41PM +0100, Alistair Popple wrote: >>> + * A pin or map that fails after dma_buf_mapping_select() may reopen the >>> + * choice only if it was the one that made it. A selection that predates the >>> + * call belongs to a live pin or mapping and must survive, otherwise the next >>> + * pin or map would reselect under it without an invalidate. >>> + */ >>> +void dma_buf_mapping_unselect(struct dma_buf_attachment *attach, >>> + bool was_selected) >>> +{ >>> + dma_resv_assert_held(attach->dmabuf->resv); >>> + >>> + if (was_selected) >>> + return; >>> + >>> + attach->selected = false; >>> + attach->selected_idx = 0; >>> +} >>> + >> >> After dma_buf_invalidate_mappings(), attach->selected is false while >> attach->selected_idx still holds that mapping's entry for a pending >> unmap. >> >> If a pin/map fails before that unmap runs, was_selected is false and >> dma_buf_mapping_unselect() resets attach->selected_idx to 0. >> >> A subsequent dma_buf_unmap_sgt() then uses matches[0]. > > Actually there's a bigger issue here. The contract at the moment states that > mapping type may change after invalidation. However that doesn't account for the > fact mappings can outlive the invalidation. > > This could be dealt with by switching everything over to the generic > dma_buf_mapping_map/unmap() path, but that requires an allocation per mapping > just to track the mapping type. You need an allocation per mapping anyway to identify the mapping anyway. We currently abuse the sg_table for that, but essentially the idea of having a structure/object to represent the mapping needs to stay around as far as I can see. Regards, Christian. > > The alternate is we update the contract to say mapping type cannot change until > after all importers have unmapped. Enforcing this would require tracking the > number of live mappings/pins per-attachment, but I think this is the better > solution so will add that for the next version. > >>> int dma_buf_pin(struct dma_buf_attachment *attach) >>> { >>> struct dma_buf *dmabuf = attach->dmabuf; >>> + bool selected = attach->selected; >>> int ret = 0; >>> >>> WARN_ON(!attach->importer_ops); >>> >>> dma_resv_assert_held(dmabuf->resv); >>> >>> - if (dmabuf->ops->pin) >>> + ret = dma_buf_mapping_select(attach); >>> + if (ret) >>> + return ret; >>> + >>> + if (dmabuf->ops->pin) { >>> ret = dmabuf->ops->pin(attach); >>> + if (ret) >>> + dma_buf_mapping_unselect(attach, selected); >>> + } >> >> dma_buf_mapping_select() sets attach->selected = true before ops->pin() >> and the map callbacks run. >> >> In patches 14/15, xe/amdgpu migrate a VRAM buffer to system memory >> during pin and map when the attachment does not accept P2P. >> >> That migration calls dma_buf_invalidate_mappings() and clears >> attach->selected on every attachment, also the one being pinned/mapped. >> >> When the callback succeeds, the attachment stays pinned or mapped with >> attach->selected == false. >> >> A later map/pin on the same attachment can then reselect without an >> invalidation. > > Argh. Thanks. Will fix. > > - Alistair > >> Thanks, >> Karl

2 days, 8 hours

Re: [PATCH v2 0/3] media: synchronize CPU access to imported DMA-BUFs

by Laurent Pinchart

Hi Karl, We discussed in v1 how this is not the right approach. Why are you posting a v2 without addressing that ? You need to go back to the design table. On Sat, Nov 07, 2026 at 11:47:00AM +0100, Karl Mehltretter wrote: > uvcvideo and vivid (when using vb2-vmalloc) access imported DMA-BUFs > through a kernel vmap without cache synchronization. When a non-coherent > importer such as V3D maps the same DMA-BUF persistently, captured data > remains in the CPU cache while physical RAM holds stale bytes. > > Add an opt-in uses_cpu_access queue flag for vb2-vmalloc queues to > bracket the interval from buf_prepare() through buf_finish() with > dma_buf_begin_cpu_access() and dma_buf_end_cpu_access(). Keep this > opt-in because some vb2-vmalloc drivers pass imported buffers to > hardware, and end CPU access in process context because DMA-BUF > callbacks may sleep. > > This follows the per-queue flag proposed here: > https://lore.kernel.org/r/CAAFQd5Am5jBev5P1HmsdeHoJfROZat3bi1W=UsN7wpVqw-XU… > > Based on Linux 7.4-rc1 with prerequisite patch "media: videobuf2: finish > prepared buffers in VIDIOC_REMOVE_BUFS": > https://lore.kernel.org/r/20261026071735.37220-1-kmehltretter@gmail.com/ > > Changes in v2: > - Split patch 1 of v1 into the standalone VIDIOC_REMOVE_BUFS patch above > and use its __vb2_buf_cancel() helper so queue cancellation and > VIDIOC_REMOVE_BUFS share the finish path (Tomasz). > - Scope uses_cpu_access to vb2-vmalloc queues and drop the attach_dmabuf > dma_dir parameter from vb2_mem_ops, videobuf2-dma-contig, > videobuf2-dma-sg and videobuf2-vmalloc (Tomasz). > - Enable uses_cpu_access in vivid only when vivid uses > vb2_vmalloc_memops (Tomasz). > > Link to v1: > https://lore.kernel.org/r/cover.1792392288.git.kmehltretter@gmail.com/ > > Testing: > > - Raspberry Pi 500+ (6.18.34+rpt-rpi-2712, aarch64, 16 KiB pages, > Sunplus UVC camera 1bcf:2701 and Broadcom V3D 7.1 GPU), backport of > the prerequisite patch plus patches 1 and 2: eight 640x480 YUYV frames > (614,400 B) captured into DMA-BUFs pre-seeded with 0xA5 and imported > into persistent EGL_LINUX_DMA_BUF_EXT textures before VIDIOC_STREAMON, > then copied by V3D 7.1 immediately after VIDIOC_DQBUF: > > Heap Baseline stale Patched v2 stale > /dev/dma_heap/linux,cma 8/8 (329,890 B) 0/8 (0 B) > /dev/dma_heap/system 8/8 (509,818 B) 0/8 (0 B) > > - QEMU virt (arm64, Linux 7.4-rc1 with the prerequisite patch and > patches 1-3, VIDEO_ADV_DEBUG=y, DEBUG_ATOMIC_SLEEP=y): six vivid > lifecycle cases (stream, streamoff-queued, prepare-reqbufs0, > prepare-remove, close-streaming, replace-dmabuf) across single-planar > and multi-planar queues with kprobe counters on > dma_buf_begin_cpu_access() and dma_buf_end_cpu_access(): > > Queue begin/end calls Unbalanced Warnings > vivid vb2-vmalloc (SP) 34 / 34 0 0 > vivid vb2-vmalloc (MP) 34 / 34 0 0 > vivid vb2-dma-contig (SP) 0 / 0 0 0 > vivid vb2-dma-contig (MP) 0 / 0 0 0 > 20x prepare-remove (vmalloc) 20 / 20 0 0 > > Assisted by an LLM for code changes, test harnesses and commit message > drafting. > > Karl Mehltretter (3): > media: videobuf2: add opt-in DMA-BUF CPU access > media: uvcvideo: synchronize imported DMA-BUFs for CPU access > media: vivid: synchronize imported DMA-BUFs for CPU access > > .../media/common/videobuf2/videobuf2-core.c | 76 +++++++++++++++++++ > drivers/media/test-drivers/vivid/vivid-core.c | 4 +- > drivers/media/usb/uvc/uvc_queue.c | 1 + > include/media/videobuf2-core.h | 5 ++ > 4 files changed, 85 insertions(+), 1 deletion(-) > > > base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4 > prerequisite-patch-id: aa99d5c3c27082cbe003ed94a195e3de415777c9 > -- > 2.39.5 (Apple Git-154) -- Regards, Laurent Pinchart

4 days, 8 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig