Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

43 participants
6398 discussions

by Emma Stone

I often get this question in my mind when I think about visiting the mountains — is Leh Ladakh safe for visitors like me? The place looks absolutely beautiful in photos, with huge mountains, quiet monasteries, and those long scenic roads. But at the same time, I always wonder about the altitude, weather, and road conditions. Since it’s a high-altitude region, I feel it’s important to understand how the body reacts there and how much time I should give myself to adjust. From what I’ve learned so far, many travelers visit every year and most of them have a wonderful experience. Still, I always prefer to read carefully and plan things before going anywhere new. I like checking routes, the best months to visit, and what kind of preparations I should make. That’s why I started looking through a Leh Ladakh travel guide, because it answers many of the small questions I have in my mind. I also feel safer knowing that tourism is common there and local people are welcoming to visitors. So maybe the real question for me is not just safety, but how well I plan my trip. With the right preparation, the journey can be amazing. 🏔️✨ More details: https://www.indiahighlight.com/destination/leh-ladakh 📧 emmastone(a)yzcalo.com 📞 19707840507

1 month, 1 week

[PATCH] udmabuf: fix DMA direction mismatch in release_udmabuf()

by Mikhail Gavrilov

begin_cpu_udmabuf() maps the sg_table with the caller-provided direction (e.g., DMA_TO_DEVICE for a write-only sync), and caches it in ubuf->sg for reuse. However, release_udmabuf() always unmaps this sg_table with a hardcoded DMA_BIDIRECTIONAL, regardless of the direction that was originally used for the mapping. With CONFIG_DMA_API_DEBUG=y this produces: DMA-API: misc udmabuf: device driver frees DMA memory with different direction [device address=0x000000044a123000] [size=4096 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] The issue was found during video playback when GStreamer performed a write-only DMA_BUF_IOCTL_SYNC on a udmabuf. It can be reproduced with CONFIG_DMA_API_DEBUG=y by creating a udmabuf from a memfd, performing a write-only sync (DMA_BUF_SYNC_WRITE without DMA_BUF_SYNC_READ), and closing the file descriptor. Fix this by storing the DMA direction used when the sg_table is first created in begin_cpu_udmabuf(), and passing that same direction to put_sg_table() in release_udmabuf(). Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable(a)vger.kernel.org Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com> --- drivers/dma-buf/udmabuf.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 94b8ecb892bb..d0836febefdd 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -40,6 +40,7 @@ struct udmabuf { struct folio **pinned_folios; struct sg_table *sg; + enum dma_data_direction sg_dir; struct miscdevice *device; pgoff_t *offsets; }; @@ -235,7 +236,7 @@ static void release_udmabuf(struct dma_buf *buf) struct device *dev = ubuf->device->this_device; if (ubuf->sg) - put_sg_table(dev, ubuf->sg, DMA_BIDIRECTIONAL); + put_sg_table(dev, ubuf->sg, ubuf->sg_dir); deinit_udmabuf(ubuf); kfree(ubuf); @@ -253,6 +254,8 @@ static int begin_cpu_udmabuf(struct dma_buf *buf, if (IS_ERR(ubuf->sg)) { ret = PTR_ERR(ubuf->sg); ubuf->sg = NULL; + } else { + ubuf->sg_dir = direction; } } else { dma_sync_sgtable_for_cpu(dev, ubuf->sg, direction); -- 2.53.0

1 month, 1 week

[RFC v2 PATCH 00/10] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi all, There were various suggestions in the September 2025 thread "[TECH TOPIC] vfio, iommufd: Enabling user space drivers to vend more granular access to client processes" [0], and LPC discussions, around improving the situation for multi-process userspace driver designs. This RFC series implements some of these ideas. (Thanks for feedback on v1! Revised series, with changes noted inline.) Background: Multi-process USDs ============================== The userspace driver scenario discussed in that thread involves a primary process driving a PCIe function through VFIO/iommufd, which manages the function-wide ownership/lifecycle. The function is designed to provide multiple distinct programming interfaces (for example, several independent MMIO register frames in one function), and the primary process delegates control of these interfaces to multiple independent client processes (which do the actual work). This scenario clearly relies on a HW design that provides appropriate isolation between the programming interfaces. The two key needs are: 1. Mechanisms to safely delegate a subset of the device MMIO resources to a client process without over-sharing wider access (or influence over whole-device activities, such as reset). 2. Mechanisms to allow a client process to do its own iommufd management w.r.t. its address space, in a way that's isolated from DMA relating to other clients. mmap() of VFIO DMABUFs ====================== This RFC addresses #1 in "vfio/pci: Support mmap() of a VFIO DMABUF", implementing the proposals in [0] to add mmap() support to the existing VFIO DMABUF exporter. This enables a userspace driver to define DMABUF ranges corresponding to sub-ranges of a BAR, and grant a given client (via a shared fd) the capability to access (only) those sub-ranges. The VFIO device fds would be kept private to the primary process. All the client can do with that fd is map (or iomap via iommufd) that specific subset of resources, and the impact of bugs/malice is contained. (We'll follow up on #2 separately, as a related-but-distinct problem. PASIDs are one way to achieve per-client isolation of DMA; another could be sharing of a single IOVA space via 'constrained' iommufds.) New in v2: To achieve this, the existing VFIO BAR mmap() path is converted to use DMABUFs behind the scenes, in "vfio/pci: Convert BAR mmap() to use a DMABUF" plus new helper functions, as Jason/Christian suggested in the v1 discussion [3]. This means: - Both regular and new DMABUF BAR mappings share the same vm_ops, i.e. mmap()ing DMABUFs is a smaller change on top of the existing mmap(). - The zapping of mappings occurs via vfio_pci_dma_buf_move(), and the vfio_pci_zap_bars() originally paired with the _move()s can go away. Each DMABUF has a unique address_space. - It's a step towards future iommufd VFIO Type1 emulation implementing P2P, since iommufd can now get a DMABUF from a VA that it's mapping for IO; the VMAs' vm_file is that of the backing DMABUF. Revocation/reclaim ================== Mapping a BAR subset is useful, but the lifetime of access granted to a client needs to be managed well. For example, a protocol between the primary process and the client can indicate when the client is done, and when it's safe to reuse the resources elsewhere, but cleanup can't practically be cooperative. For robustness, we enable the driver to make the resources guaranteed-inaccessible when it chooses, so that it can re-assign them to other uses in future. "vfio/pci: Permanently revoke a DMABUF on request" adds a new VFIO device fd ioctl, VFIO_DEVICE_PCI_DMABUF_REVOKE. This takes a DMABUF fd parameter previously exported (from that device!) and permanently revokes the DMABUF. This notifies/detaches importers, zaps PTEs for any mappings, and guarantees no future attachment/import/map/access is possible by any means. A primary driver process would use this operation when the client's tenure ends to reclaim "loaned-out" MMIO interfaces, at which point the interfaces could be safely re-used. New in v2: ioctl() on VFIO driver fd, rather than DMABUF fd. A DMABUF is revoked using code common to vfio_pci_dma_buf_move(), selectively zapping mappings (after waiting for completion on the dma_buf_invalidate_mappings() request). BAR mapping access attributes ============================= Inspired by Alex [Mastro] and Jason's comments in [0] and Mahmoud's work in [1] with the goal of controlling CPU access attributes for VFIO BAR mappings (e.g. WC), we can decorate DMABUFs with access attributes that are then used by a mapping's PTEs. I've proposed reserving a field in struct vfio_device_feature_dma_buf's flags to specify an attribute for its ranges. Although that keeps the (UAPI) struct unchanged, it means all ranges in a DMABUF share the same attribute. I feel a single attribute-to-mmap() relation is logical/reasonable. An application can also create multiple DMABUFs to describe any BAR layout and mix of attributes. Tests ===== (Still sharing the [RFC ONLY] userspace test/demo program for context, not for merge.) It illustrates & tests various map/revoke cases, but doesn't use the existing VFIO selftests and relies on a (tweaked) QEMU EDU function. I'm (still) working on integrating the scenarios into the existing VFIO selftests. This code has been tested in mapping DMABUFs of single/multiple ranges, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings seem to work correctly. I've lightly tested WC mappings also (by observing resulting PTEs as having the correct attributes...). Fin === v2 is based on next-20260310 (to build on Leon's recent series "vfio: Wait for dma-buf invalidation to complete" [2]). Please share your thoughts! I'd like to de-RFC if we feel this approach is now fair. Many thanks, Matt References: [0]: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ [1]: https://lore.kernel.org/all/20250804104012.87915-1-mngyadam@amazon.de/ [2]: https://lore.kernel.org/linux-iommu/20260205-nocturnal-poetic-chamois-f566a… [3]: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ -------------------------------------------------------------------------------- Changelog: v2: Respin based on the feedback/suggestions: - Transform the existing VFIO BAR mmap path to also use DMABUFs behind the scenes, and then simply share that code for explicitly-mapped DMABUFs. - Refactors the export itself out of vfio_pci_core_feature_dma_buf, and shared by a new vfio_pci_core_mmap_prep_dmabuf helper used by the regular VFIO mmap to create a DMABUF. - Revoke buffers using a VFIO device fd ioctl v1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ Matt Evans (10): vfio/pci: Set up VFIO barmap before creating a DMABUF vfio/pci: Clean up DMABUFs before disabling function vfio/pci: Add 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: Remove vfio_pci_zap_bars() vfio/pci: Support mmap() of a VFIO DMABUF vfio/pci: Permanently revoke a DMABUF on request vfio/pci: Add mmap() attributes to DMABUF feature [RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test drivers/vfio/pci/Kconfig | 3 +- drivers/vfio/pci/Makefile | 3 +- drivers/vfio/pci/vfio_pci_config.c | 18 +- drivers/vfio/pci/vfio_pci_core.c | 123 +-- drivers/vfio/pci/vfio_pci_dmabuf.c | 425 +++++++-- drivers/vfio/pci/vfio_pci_priv.h | 46 +- include/uapi/linux/vfio.h | 42 +- tools/testing/selftests/vfio/Makefile | 1 + .../vfio/standalone/vfio_dmabuf_mmap_test.c | 837 ++++++++++++++++++ 9 files changed, 1339 insertions(+), 159 deletions(-) create mode 100644 tools/testing/selftests/vfio/standalone/vfio_dmabuf_mmap_test.c -- 2.47.3

1 month, 1 week

[PATCH v1] i2c: qcom-geni: Skip extra TX DMA TRE for single read message in GPI mode

by Aniket Randive

In GPI mode, the I2C GENI driver incorrectly generates an extra TX DMA TRE on the TX channel during single read message transfer. This results in an unnecessary write operation on the I2C bus, which is not required. Update the logic to avoid generating the extra TX DMA TRE for single read message, ensuring correct behavior and preventing redundant transfers. Co-developed-by: Maramaina Naresh <naresh.maramaina(a)oss.qualcomm.com> Signed-off-by: Maramaina Naresh <naresh.maramaina(a)oss.qualcomm.com> Signed-off-by: Aniket Randive <aniket.randive(a)oss.qualcomm.com> --- drivers/i2c/busses/i2c-qcom-geni.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index a4acb78fafb6..2706309bbebb 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -625,8 +625,8 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], { struct gpi_i2c_config *peripheral; unsigned int flags; - void *dma_buf; - dma_addr_t addr; + void *dma_buf = NULL; + dma_addr_t addr = 0; enum dma_data_direction map_dirn; enum dma_transfer_direction dma_dirn; struct dma_async_tx_descriptor *desc; @@ -639,6 +639,11 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], gi2c_gpi_xfer = &gi2c->i2c_multi_desc_config; msg_idx = gi2c_gpi_xfer->msg_idx_cnt; + if (op == I2C_WRITE && msgs[msg_idx].flags & I2C_M_RD) { + peripheral->multi_msg = true; + goto skip_dma; + } + dma_buf = i2c_get_dma_safe_msg_buf(&msgs[msg_idx], 1); if (!dma_buf) { ret = -ENOMEM; @@ -668,6 +673,7 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], flags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK; } +skip_dma: /* set the length as message for rx txn */ peripheral->rx_len = msgs[msg_idx].len; peripheral->op = op; @@ -740,9 +746,11 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], return 0; err_config: - dma_unmap_single(gi2c->se.dev->parent, addr, - msgs[msg_idx].len, map_dirn); - i2c_put_dma_safe_msg_buf(dma_buf, &msgs[msg_idx], false); + if (op == I2C_WRITE && (msgs[msg_idx].flags & I2C_M_RD)) { + dma_unmap_single(gi2c->se.dev->parent, addr, + msgs[msg_idx].len, map_dirn); + i2c_put_dma_safe_msg_buf(dma_buf, &msgs[msg_idx], false); + } out: gi2c->err = ret; --- base-commit: 785f0eb2f85decbe7c1ef9ae922931f0194ffc2e change-id: 20260325-skip_extra_dma_tre-a3cf22f81d9b Best regards, -- Aniket Randive <aniket.randive(a)oss.qualcomm.com>

1 month, 1 week

[PATCH v2] dma/contiguous: Fix broken build

by Maxime Ripard

Commit 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic around") didn't remove one last call to dma_heap_cma_register_heap() that it removed, thus breaking the build. That last call is in dma_contiguous_reserve(), to handle the registration of the default CMA region heap instance. The default CMA region instance is already somewhat handled by retrieving it through the dev_get_cma_area() call in the CMA heap driver. However, since commit 854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name"), we will create two heap instances for the CMA default region. The first one is always called "default_cma_region", and is the one handled by the call to dev_get_cma_area() mentioned earlier. The second one is the name it used to have prior to that last commit for backward compatibility. In the case where the default CMA region is defined in the DT, then that region is registered through rmem_cma_setup() and that region is added to the list of CMA regions to create a CMA heap instance for. In the case where the default CMA region is not defined in the DT though used to be the case covered by the now removed dma_heap_cma_register_heap() in dma_contiguous_reserve(). If we only remove the call to dma_heap_cma_register_heap(), then the legacy name of the CMA heap will not be registered anymore. We thus need to replace that call with a call to rmem_cma_insert_area() to make sure we queue this instance, if created, to create a heap instance. Once that call to dma_heap_cma_register_heap() replaced, we can also remove the now unused function definition, its now empty header, and all includes of this header. Fixes: 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic around") Reported-by: Mark Brown <broonie(a)kernel.org> Closes: https://lore.kernel.org/linux-next/acbjaDJ1a-YQC64d@sirena.co.uk/ Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v2: - Fix creation of the CMA heap instance with the legacy name when not declared in the DT. - Link to v1: https://lore.kernel.org/r/20260330-dma-build-fix-v1-1-748b64f0d8af@kernel.o… --- drivers/dma-buf/heaps/cma_heap.c | 1 - include/linux/dma-buf/heaps/cma.h | 16 ---------------- kernel/dma/contiguous.c | 14 +++++++++++--- 3 files changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 7216a14262b04bb6130ddf26b7d009f7d15b03fd..9a8b36bc929f6daa483a0139a2919d95127e0d23 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -12,11 +12,10 @@ #define pr_fmt(fmt) "cma_heap: " fmt #include <linux/cma.h> #include <linux/dma-buf.h> -#include <linux/dma-buf/heaps/cma.h> #include <linux/dma-heap.h> #include <linux/dma-map-ops.h> #include <linux/err.h> #include <linux/highmem.h> #include <linux/io.h> diff --git a/include/linux/dma-buf/heaps/cma.h b/include/linux/dma-buf/heaps/cma.h deleted file mode 100644 index e751479e21e703e24a5f799b4a7fc8bd0df3c1c4..0000000000000000000000000000000000000000 --- a/include/linux/dma-buf/heaps/cma.h +++ /dev/null @@ -1,16 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef DMA_BUF_HEAP_CMA_H_ -#define DMA_BUF_HEAP_CMA_H_ - -struct cma; - -#ifdef CONFIG_DMABUF_HEAPS_CMA -int dma_heap_cma_register_heap(struct cma *cma); -#else -static inline int dma_heap_cma_register_heap(struct cma *cma) -{ - return 0; -} -#endif // CONFIG_DMABUF_HEAPS_CMA - -#endif // DMA_BUF_HEAP_CMA_H_ diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index ad50512d71d3088a73e4b1ac02d6e6122374888e..d5d15983060c5c54744d6a63f2b591e1a3455b86 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -40,11 +40,10 @@ #include <asm/page.h> #include <linux/memblock.h> #include <linux/err.h> #include <linux/sizes.h> -#include <linux/dma-buf/heaps/cma.h> #include <linux/dma-map-ops.h> #include <linux/cma.h> #include <linux/nospec.h> #ifdef CONFIG_CMA_SIZE_MBYTES @@ -217,10 +216,19 @@ static void __init dma_numa_cma_reserve(void) static inline void __init dma_numa_cma_reserve(void) { } #endif +#ifdef CONFIG_OF_RESERVED_MEM +static int rmem_cma_insert_area(struct cma *cma); +#else +static inline int rmem_cma_insert_area(struct cma *cma) +{ + return 0; +} +#endif + /** * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling * @limit: End address of the reserved memory (optional, 0 for any). * * This function reserves memory from early allocator. It should be @@ -271,13 +279,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit) &dma_contiguous_default_area, fixed); if (ret) return; - ret = dma_heap_cma_register_heap(dma_contiguous_default_area); + ret = rmem_cma_insert_area(dma_contiguous_default_area); if (ret) - pr_warn("Couldn't register default CMA heap."); + pr_warn("Couldn't queue default CMA region for heap creation."); } } void __weak dma_contiguous_early_fixup(phys_addr_t base, unsigned long size) --- base-commit: 6c683d5b1903a14e362c9f1628ce9fe61eac35e7 change-id: 20260330-dma-build-fix-706a4feb0e0f Best regards, -- Maxime Ripard <mripard(a)kernel.org>

1 month, 1 week

[PATCH] dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning

by Mikhail Gavrilov

When CONFIG_DMA_API_DEBUG_SG is enabled, importing a udmabuf into a DRM driver (e.g. amdgpu for video playback in GNOME Videos / Showtime) triggers a spurious warning: DMA-API: amdgpu 0000:03:00.0: cacheline tracking EEXIST, \ overlapping mappings aren't supported WARNING: kernel/dma/debug.c:619 at add_dma_entry+0x473/0x5f0 The call chain is: amdgpu_cs_ioctl -> amdgpu_ttm_backend_bind -> dma_buf_map_attachment -> [udmabuf] map_udmabuf -> get_sg_table -> dma_map_sgtable(dev, sg, direction, 0) // attrs=0 -> debug_dma_map_sg -> add_dma_entry -> EEXIST This happens because udmabuf builds a per-page scatter-gather list via sg_set_folio(). When begin_cpu_udmabuf() has already created an sg table mapped for the misc device, and an importer such as amdgpu maps the same pages for its own device via map_udmabuf(), the DMA debug infrastructure sees two active mappings whose physical addresses share cacheline boundaries and warns about the overlap. The DMA_ATTR_SKIP_CPU_SYNC flag suppresses this check in add_dma_entry() because it signals that no CPU cache maintenance is performed at map/unmap time, making the cacheline overlap harmless. All other major dma-buf exporters already pass this flag: - drm_gem_map_dma_buf() passes DMA_ATTR_SKIP_CPU_SYNC - amdgpu_dma_buf_map() passes DMA_ATTR_SKIP_CPU_SYNC The CPU sync at map/unmap time is also redundant for udmabuf: begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU access is requested through the dma-buf interface. Pass DMA_ATTR_SKIP_CPU_SYNC to dma_map_sgtable() and dma_unmap_sgtable() in udmabuf to suppress the spurious warning and skip the redundant sync. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable(a)vger.kernel.org Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com> --- drivers/dma-buf/udmabuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 94b8ecb892bb..9c6f8785a28a 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -162,7 +162,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE, ubuf->offsets[i]); - ret = dma_map_sgtable(dev, sg, direction, 0); + ret = dma_map_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); if (ret < 0) goto err_map; return sg; @@ -177,7 +177,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, static void put_sg_table(struct device *dev, struct sg_table *sg, enum dma_data_direction direction) { - dma_unmap_sgtable(dev, sg, direction, 0); + dma_unmap_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); sg_free_table(sg); kfree(sg); } -- 2.53.0

1 month, 1 week

[PATCH v9 0/7] Rust bindings for gem shmem

by Lyude Paul

This is the next version of the shmem backed GEM objects series originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/156093/ This patch series may be applied on top of the driver-core/driver-core-testing branch: https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git… Changelogs are per-patch Asahi Lina (2): rust: helpers: Add bindings/wrappers for dma_resv_lock rust: drm: gem: shmem: Add DRM shmem helper abstraction Lyude Paul (5): rust: drm: Add gem::impl_aref_for_gem_obj! rust: drm: gem: Add raw_dma_resv() function rust: gem: Introduce DriverObject::Args rust: drm: gem: Introduce shmem::SGTable rust: drm/gem: Add vmap functions to shmem bindings drivers/gpu/drm/nova/gem.rs | 5 +- drivers/gpu/drm/tyr/gem.rs | 3 +- rust/bindings/bindings_helper.h | 3 + rust/helpers/dma-resv.c | 13 + rust/helpers/drm.c | 56 ++- rust/helpers/helpers.c | 1 + rust/kernel/drm/gem/mod.rs | 79 +++- rust/kernel/drm/gem/shmem.rs | 654 ++++++++++++++++++++++++++++++++ 8 files changed, 792 insertions(+), 22 deletions(-) create mode 100644 rust/helpers/dma-resv.c create mode 100644 rust/kernel/drm/gem/shmem.rs base-commit: dc33ae50d32b509af5ae61030912fa20c79ef112 prerequisite-patch-id: c631986f96e2073263e97e82a65b96fc5ada6924 prerequisite-patch-id: ae853e8eb8d58c77881371960be4ae92755e83c6 prerequisite-patch-id: 0ab78b50648c7d8f66b83c32ed2af0ec3ede42a3 prerequisite-patch-id: 636ec7f913f4047e5e1a1788f3e835b7259698c2 prerequisite-patch-id: d75e4d7140eadeeed8017af8cd093bfd2766ee8e prerequisite-patch-id: 67a8010c1bc95bca1d2cf6b246c67bc79d24e766 -- 2.53.0

1 month, 1 week

[PATCH RESEND] dma-fence: Dereference correct dma_fence in dma_fence_chain_find_seqno()

by Li Ming

dma_fence_chain_find_seqno() uses dma_fence_chain_for_each() to walk a given dma_fence_chain. dma_fence_chain_for_each() always holds a reference for the current fence during iteration. The reference must be dropped after breaking out. Instead of dereferencing the last fence as intended, dma_fence_chain_find_seqno() incorrectly dereferences the first fence in the chain. Fixes: 7bf60c52e093 ("dma-buf: add new dma_fence_chain container v7") Signed-off-by: Li Ming <ming.li(a)zohomail.com> --- drivers/dma-buf/dma-fence-chain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c index a8a90acf4f34..71fa173aef13 100644 --- a/drivers/dma-buf/dma-fence-chain.c +++ b/drivers/dma-buf/dma-fence-chain.c @@ -103,7 +103,7 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t seqno) to_dma_fence_chain(*pfence)->prev_seqno < seqno) break; } - dma_fence_put(&chain->base); + dma_fence_put(*pfence); return 0; } --- base-commit: c369299895a591d96745d6492d4888259b004a9e change-id: 20260327-fix_dma_fence_chain_find_seqno-7adea64efe01 Best regards, -- Li Ming <ming.li(a)zohomail.com>

1 month, 2 weeks

[PATCH] dma/contiguous: Fix broken build

by Maxime Ripard

1 month, 2 weeks

Expertise in Recovery

by penelopestaunton931＠gmail.com

Safeguard is not just another name in the crowded field of cryptocurrency recovery; they are renowned for their effectiveness and expertise in tracing lost funds. Their team comprises skilled professionals who understand the intricate workings of blockchain technology and the tactics employed by online scammers. This specialized knowledge enables them to devise tailored strategies to recover your assets. Email: safeguardbitcoin(a)consultant.com WhatsApp: +44 7426 168300 Website: https://safeguardbitcoin.wixsite.com/safeguard-bitcoin--1

1 month, 2 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig