Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

18 participants
3713 discussions

[PATCH bpf] selftests/bpf: Test that a drained dmabuf iterator keeps returning NULL

by T.J. Mercier

The BPF iterator docs in bpf_iterators.rst specify that the next function of an open-coded iterator should keep returning NULL after it has been returned once. Add a subtest that checks this for the dmabuf iterator. It drains an iterator, calls bpf_iter_dmabuf_next() once more and checks that the result is NULL. The dma-bufs the test creates keep the list from being empty, so an iterator that starts over would return one of them. The existing open_coded subtest uses bpf_for_each(), which stops at the first NULL and never calls next() on a drained iterator. Signed-off-by: T.J. Mercier <tjmercier(a)google.com> --- This depends on Kang Chen's fix and fails without it: https://lore.kernel.org/bpf/20261110125106.2935677-1-k.chen@smail.nju.edu.c… Kang, feel free to carry it as 2/2 in your v2. .../selftests/bpf/prog_tests/dmabuf_iter.c | 19 +++++++++++++++++++ .../testing/selftests/bpf/progs/dmabuf_iter.c | 19 +++++++++++++++++++ 2 files changed, 38 insertions(+) diff --git a/tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c b/tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c index 1a5dc1adae73..c1f81b5dccdc 100644 --- a/tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c +++ b/tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c @@ -265,6 +265,23 @@ static void subtest_dmabuf_iter_check_open_coded(struct dmabuf_iter *skel, int m } while (bpf_map_get_next_key(map_fd, key, key)); } +static void subtest_dmabuf_iter_check_next_after_drain(struct dmabuf_iter *skel) +{ + LIBBPF_OPTS(bpf_test_run_opts, topts); + int err, fd; + + fd = bpf_program__fd(skel->progs.iter_dmabuf_next_after_drain); + + err = bpf_prog_test_run_opts(fd, &topts); + if (!ASSERT_OK(err, "test_run_opts err")) + return; + if (!ASSERT_OK(topts.retval, "test_run_opts retval")) + return; + + /* The test buffers exist, so a restarted iteration would find one */ + ASSERT_EQ(skel->data->next_after_drain, 0, "next_after_drain"); +} + void test_dmabuf_iter(void) { struct dmabuf_iter *skel = NULL; @@ -315,6 +332,8 @@ void test_dmabuf_iter(void) } if (test__start_subtest("open_coded")) subtest_dmabuf_iter_check_open_coded(skel, map_fd); + if (test__start_subtest("next_after_drain")) + subtest_dmabuf_iter_check_next_after_drain(skel); destroy: destroy_test_buffers(); diff --git a/tools/testing/selftests/bpf/progs/dmabuf_iter.c b/tools/testing/selftests/bpf/progs/dmabuf_iter.c index 9cbb7442646e..d5421b75c39c 100644 --- a/tools/testing/selftests/bpf/progs/dmabuf_iter.c +++ b/tools/testing/selftests/bpf/progs/dmabuf_iter.c @@ -99,3 +99,22 @@ int iter_dmabuf_for_each(const void *ctx) return 0; } + +/* Result of a bpf_iter_dmabuf_next() call after the iterator was drained */ +__u64 next_after_drain = -1; + +SEC("syscall") +int iter_dmabuf_next_after_drain(const void *ctx) +{ + struct bpf_iter_dmabuf it; + + bpf_iter_dmabuf_new(&it); + while (bpf_iter_dmabuf_next(&it)) + ; + + /* Store the raw value; the verifier would remove a branch on it */ + next_after_drain = (__u64)bpf_iter_dmabuf_next(&it); + bpf_iter_dmabuf_destroy(&it); + + return 0; +} -- 2.56.0.567.gdb80ae8cd5-goog

23 hours, 14 minutes

[PATCH v4 0/8] memcg: dma-buf cgroup accounting and charge transfer

by Albert Esteve

Shared-memory allocator services (e.g., Android's gralloc) allocate dma-bufs on behalf of client processes in different cgroups. Today those allocations are charged to the allocator's own cgroup, leaving client cgroups with no visibility into their actual memory consumption and defeating resource limits. This series adds memory cgroup accounting for dma-buf allocations, building on T.J. Mercier's earlier series [1] and incorporating feedback from previous versions and LPC discussions [2]. Patch 1 introduces the MEMCG_DMABUF stat and reserve/cancel and uncharge helpers in mm/memcontrol.c Patch 2 wires up the charging policy: dma_buf_export() stores exp_info.memcg and updates the stat, a new charge_fd field in DMA_HEAP_IOCTL_ALLOC accepts a pidfd or cgroupfd to identify the target cgroup, and __GFP_ACCOUNT is removed from system-heap allocations to avoid double counting. Patch 3 adds DMA_BUF_IOCTL_XFER_CHARGE, a general ioctl on any dma-buf fd to transfer charges post-allocation. This covers the double-hop allocator case (SurfaceFlinger -> gralloc -> kernel) and works for buffers from any exporter (DRM, V4L2, etc.). Charging is gated by dmabuf->memcg being set at export time, ensuring that transfer is only applied for buffers backed by system memory where size reflects actual bytes. If the receiving cgroup lacks capacity for the charge, the ioctl returns -ENOMEM and the original charge is preserved. Patches 4-7 add access control for cross-cgroup charging. Letting userspace decide who to charge needs to be a privileged operation because it has material impact on OOM decission and resource limits. We gate it via LSM hooks for the two charge_fd flavours: security_dma_buf_charge_task() gates the pidfd path (target identified by task credentials) and security_dma_buf_charge_cgroup() gates the cgroupfd path (target identified by cgroup directory label), with SELinux implementations under a dma_buf object class. Patch 8 adds selftests. Known limitations: - Single-owner model: a dma-buf carries one memcg charge regardless of how many processes share it. - Only memcg accounting. CMA heaps would additionally need dmem controller integration. - If a transfer of an uncharged buffer fails, the buffer remains charged to the original cgroup. The allocator (userspace) is expected to handle this (retry, free, ...). - The LSM hooks are intentionally narrow. Broader cgroup access controls (e.g. for the memfd/kexec handover case [2]) could be a separate effort reusing the same pattern. - Only system heap sets exp_info.memcg today. Other exporters (DRM, V4L2, etc.) can opt in by setting it, but are not covered by this series. - Related to the above: lazy backing-store allocation is not supported. This can be extended later, e.g., by adding a flag on the dma-buf struct for explicitly marking when memory is committed. [1] https://lore.kernel.org/cgroups/20230109213809.418135-1-tjmercier@google.co… [2] https://lpc.events/event/20/contributions/2416/ Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- Changes in v4: - Remove memcg_account flag; exp_info.memcg != NULL is the opt-in - Centralize memcg bookkeeping in dma_buf_export() - Drop mem_cgroup_commit_dmabuf() - Make mem_cgroup_transfer_charge() generic (not dma-buf specific) - Add EXPORT_SYMBOL_GPL for reserve/cancel (system_heap is tristate) - Reorder: move xfer ioctl before LSM patches - Serialize dmabuf->memcg updates with the dma-buf resv lock instead of cmpxchg - Link to v3: https://lore.kernel.org/r/20261027-v2_20230123_tjmercier_google_com-v3-0-78… Changes in v3: - Split mem_cgroup_charge_dmabuf() into reserve/commit/cancel three-phase API - Extract mem_cgroup_get_from_fd() helper shared by allocate and xfer paths - Rename __padding to flags in struct dma_buf_transfer_charge - Fix UAF race: move mod_memcg_state() before cmpxchg in transfer - Add memcg_account opt-in flag; xfer returns -EOPNOTSUPP if unset - Wrap dma_buf_charge_cgroup hook in #ifdef CONFIG_CGROUPS - Fix TOCTOU in SELinux charge_cgroup xattr length handling - Link to v2: https://lore.kernel.org/r/20261021-v2_20230123_tjmercier_google_com-v2-0-ef… Changes in v2: - Move charge_pid_fd to charge_fd, accepting cgroupfd in addition to pidfd per Christian König. - New DMA_BUF_IOCTL_XFER_CHARGE ioctl for post-allocation charge transfer on any dma-buf, not just dma-heap buffers per Christian König and T.J. Mercier. - Moved __GFP_ACCOUNT removal to patch 1 per Barry Song. - dma-buf charge/uncharge helpers take struct dma_buf * directly to avoid the need for caller to manage size calculations. - Added test_xfer_charge_cgroupfd_self to dmabuf-heap selftests. - Added LSM and SELinux hooks for cgroupfd-based charging. - Rebased to v7.3-rc7. - Link to v1: https://lore.kernel.org/r/20260512-v2_20230123_tjmercier_google_com-v1-0-63… --- Albert Esteve (7): dma-heap: charge dma-buf memory via explicit memcg dma-buf: transfer memcg charges via DMA_BUF_IOCTL_XFER_CHARGE security: dma-buf: Add dma_buf_charge_task LSM hook security: dma-buf: Add dma_buf_charge_cgroup LSM hook selinux: Restrict cross-cgroup dma-buf charging selinux: Restrict dma-buf direct cgroup charging selftests/dmabuf-heaps: Add dma-buf memcg accounting tests T.J. Mercier (1): memcg: Add MEMCG_DMABUF accounting infrastructure Documentation/admin-guide/cgroup-v2.rst | 5 + drivers/dma-buf/dma-buf.c | 50 ++++ drivers/dma-buf/dma-heap.c | 28 +- drivers/dma-buf/heaps/cma_heap.c | 3 +- drivers/dma-buf/heaps/system_heap.c | 21 +- drivers/tee/tee_heap.c | 3 +- include/linux/dma-buf.h | 9 + include/linux/dma-heap.h | 3 +- include/linux/lsm_hook_defs.h | 4 + include/linux/memcontrol.h | 47 ++++ include/linux/security.h | 18 ++ include/uapi/linux/dma-buf.h | 26 ++ include/uapi/linux/dma-heap.h | 7 + mm/memcontrol.c | 176 +++++++++++++ security/security.c | 34 +++ security/selinux/hooks.c | 44 ++++ security/selinux/include/classmap.h | 1 + tools/testing/selftests/cgroup/Makefile | 2 +- tools/testing/selftests/cgroup/test_memcontrol.c | 290 ++++++++++++++++++++- tools/testing/selftests/dmabuf-heaps/config | 1 + tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 227 +++++++++++++++- tools/testing/selftests/dmabuf-heaps/vmtest.sh | 226 ++++++++++++++++ 22 files changed, 1210 insertions(+), 15 deletions(-) --- base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907 change-id: 20260508-v2_20230123_tjmercier_google_com-f44fcfb16530 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

1 day, 5 hours

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

by Christian König

On 11/12/26 04:16, Karl Mehltretter wrote: > On Sat, Nov 07, 2026 at 12:59:46PM +0100, Laurent Pinchart wrote: >> 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. >> > > v1 ended with two conflicting positions on non-coherent DMA-BUFs: > > - Laurent [1] and Nicolas [2]: end_cpu_access(WRITE) only marks the CPU > cache dirty, and non-coherent DMA importers clean before starting DMA. > Persistent DRM/KMS imports then need a sync call on each submission. > - Christian [3]: devices must access DMA-BUFs coherently with the CPU, > using begin/end_cpu_access() around CPU accesses. Importing a buffer > with dirty CPU caches onto a non-coherent device is intentionally > unsupported. Today cma_heap and system_heap sync all mapped > attachments inside begin/end_cpu_access(). > > On my Pi 500+ with a USB UVC camera (640x480 YUYV) and V3D on CMA > DMA-BUFs: > > - Without vb2 CPU sync, V3D reads stale data on 8/8 zero-copy frames. > - With vb2 begin/end_cpu_access() on cma_heap, zero-copy V3D is clean > (0/8 stale). CPU capture takes 91 us/frame without a V3D import, and > 144 us/frame when an idle V3D PRIME import is attached. > - With a test heap that tracks CPU cache state and syncs imported BOs > at V3D job submission, zero-copy V3D stays clean (0/8 stale) and the > idle-V3D CPU read drops back to 89 us/frame. > > Question to all: should I look at opt-in cache-state tracking in > dma-buf (with a sync call before DMA submission), or keep > begin/end_cpu_access() as is and handle CPU consumers via V4L2 cache > hints? A sync call before DMA operation is something we intentionally rejected. Background is that exporters should export the buffers as they need/use it and not have specialized handling just to serve importers which would be not testable without the importer etc... What we could do is to consistently use begin/end_cpu_access() and/or let exporters expose if their buffers might be dirty in the CPU cache so that importers can properly reject them. Regards, Christian. > > [1] https://lore.kernel.org/r/20261021175900.GG15441@killaraus.ideasonboard.com/ > [2] https://lore.kernel.org/r/7e4c7707880e9092180d28484ecf674be29b40a0.camel@nd… > [3] https://lore.kernel.org/r/1e798600-5a76-412a-959c-94313629baf4@amd.com/ > > Thanks, > Karl

1 day, 5 hours

[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>

1 day, 6 hours

Re: [PATCH 4/7] tracing: account ring buffer pages and trace_array metadata to memcg

by Steven Rostedt

On Wed, 11 Nov 2026 16:47:38 +0000 Vincent Donnefort <vdonnefort(a)google.com> wrote: > On Fri, Nov 06, 2026 at 09:18:26PM +0800, Tao Cui wrote: > > From: Tao Cui <cuitao(a)kylinos.cn> > > > > Creating an instance immediately allocates two full sets of per-cpu > > ring buffers, array buffer plus snapshot, about 1.375MB per cpu per set > > on the default config, plus the trace_array and its name. None of it > > is charged: neither trace.c nor ring_buffer.c passes __GFP_ACCOUNT, > > while user_events in the same directory accounts everything it > > allocates. As the name suggests, "user_events" are for users and are special. > > > > Instance creation is currently gated by tracefs file permissions > > alone, so a > > rootful container with the host tracefs bound in can create instances > > until the host runs out of memory. You mean, "works as expected"? > Charge the ring buffer pages and > > the trace_array metadata to the creating cgroup. > > > > Signed-off-by: Tao Cui <cuitao(a)kylinos.cn> > > --- > > kernel/trace/ring_buffer.c | 8 +++++++- > > kernel/trace/trace.c | 6 +++--- > > 2 files changed, 10 insertions(+), 4 deletions(-) > > > > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c > > index 1fd28a72e6ee..676c059c112c 100644 > > --- a/kernel/trace/ring_buffer.c > > +++ b/kernel/trace/ring_buffer.c > > @@ -441,7 +441,13 @@ static struct buffer_data_page *alloc_cpu_data(int cpu, int order) > > * gracefully without invoking oom-killer and the system is not > > * destabilized. > > */ > > - mflags = GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_COMP | __GFP_ZERO; > > + /* > > + * The subbuffers are charged to the memcg of whoever caused the > > + * allocation: the creator of a trace instance, or root at boot for > > + * the global trace. > > + */ > > + mflags = GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_COMP | __GFP_ZERO | > > + __GFP_ACCOUNT; > > > > page = alloc_pages_node(cpu_to_node(cpu), mflags, order); > > if (!page) > > Hum, by default tracefs is root only. > > And even if made accessible to other users: > > 1. The life span of a trace instance is not tied to the caller. > 2. The ring buffer is shared by multiple users. Right. Is there a use case out there that allows non-admin to create an instance? Tracing ring buffers can expose a lot and should not be given to unprivileged users. What exactly is this trying to achieve? -- Steve > > Overall I am not convinced charging the creator makes much sense. > > Eventually a few allocations for iterators could be GFP_ACCOUNT. >

1 day, 16 hours

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

by T.J. Mercier

On Tue, Nov 10, 2026 at 4:57 AM Kang Chen <k.chen(a)smail.nju.edu.cn> 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> Thanks for this fix. The cgroup (bpf_iter_css_next) and scx_dsq (bpf_iter_scx_dsq_next) iterators look like they also have this problem. > --- > 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. > + */ This comment explains why this patch uses a sentinel instead of growing the state, but that doesn't help anyone reading this code in the future. This belongs in the commit message, not a code comment. The real constraint is that the size of bpf_iter_dmabuf is user-visible API, so it can't grow without breaking backwards compatibility. > +#define DMABUF_ITER_DONE ((struct dma_buf *)1L) I would prefer this to be DMABUF_ITER_START to mirror the kmem_cache iterator. Then the second if (!kit->dmabuf) block in bpf_iter_dmabuf_next() below could also be removed. > + > __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. > + */ Same here, this is commit message material. If you want to add a code comment, referencing the rule from bpf_iterators.rst should be enough: /* Once NULL is returned, subsequent next calls should keep returning NULL. */ > + 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 I think we should also add a test for this. I've sent one as a reply to this thread. It fails without your fix and passes with it. Feel free to add it as 2/2 in v2.

1 day, 19 hours

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 >

1 day, 19 hours

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

2 days, 1 hour

[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

2 days, 4 hours

[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

2 days, 19 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig