Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

5 participants
3689 discussions

Re: [PATCH v19 00/40] DEPT(DEPendency Tracker)

by Byungchul Park

On Fri, Aug 21, 2026 at 09:56:05AM +0200, David Hildenbrand (Arm) wrote: [...] > >>> Q. Why not build DEPT into lockdep? > >>> > >>> A. Lockdep is stable, battle-tested code. I chose separation because > >>> while DEPT borrows BFS and hashing ideas, the wait/event model > >>> requires rebuilding from scratch. Lockdep was designed for lock > >>> acquisition order — retrofitting it would risk its stability. > >> > >> Why can't this just be some configurable extension to lockdep > >> (CONFIG_LOCKDEP_XYZ) until the feature is stable and can unconditionally be > >> enabled along with it? > > > > Answered? > > Not quite. I don't understand why this must be a completely separate machinery, > even if, conceptually, it would do more than traditional lockdep. > > Is it either DEPT or LOCKDEP in current configurations? Can both run at the same > time? Yes. > > > >> I don't quite buy the "would risk its stability" argument. A lot of stuff we do > >> "risks stability", every day :) > > > > That's awsome anyway :) > > > >> Is there another good reason (incompatible with X, dangerous with Y, cinfusing > >> Z) why this really must be a separate thing? > > > > Roughly: > > > > 1. Similar or less effort is needed for the new one - retrofitting > > lockdep is not easy and big changes are required since the > > reusable parts are not that big. > > > > 2. Even though you didn't agree, retrofitting it would risk its > > stability. > > Well, I don't buy the stability argument, really :) > > Retrofitting effort for lockdep is an interesting point, though. Lockdep > maintainers would have to make the call here regarding direction and feasibility. > > [...] > > >> But I am not a locking maintainer. I think there was plenty of discussion in the > >> past, so I might just be raising points that were already discussed in the past, > >> but I really just read some random pieces of earlier discussions. (ideally > >> previous discussions would be summarized here) > >> > >> Long story short: we are now in v19 and I think there was pushback in the past. > >> Did the opinion of locking maintainers change, or is there a way forward to > >> integrate this in a way that would make locking maintainers accept this? > > > > One of locking maintainers who I met in an LPC told me that he agrees > > with the direction of DEPT and supports DEPT, not officially tho. > > Hm. > > > > > What he and other people are concerning w.r.t DEPT the most is, false > > positives, which is the most important issue for now. > > Thanks for highlighting that. What's the main reason for false positives? Is it > something conceptual that is mostly impossible to solve, or rather just > implementation work to cover all edge cases? It's because of lack of annotations for proper classification. As Willy mentioned, different call paths for various usages should be annotated with different classes throughout the kernel. > > At the same time, I think the most important thing is to make DEPT > > useful in practice especially with folio locks involved. Actually, I'm > > planning to share DEPT's true reports periodically to LKML and work with > > people who believe DEPT can make things better. > > > > Any advices will be welcome. Thanks for your opinions. > > I think we must come to some conclusion on how to proceed with DEPT. I see the > following options: > > (1) Don't merge it and carry it OOT. Shame if it delivers real value. > > (2) Merge it (after proper review and acks from relevant maintainers ;) ), > keeping it entirely separate from lockdep. > > (3) Integrate it with lockdep on a high level, giving us a single locking > dependency checker, but mostly letting dept have a separate implementation. > Look into possible merging afterwards. > > (4) Retrofit and extend lockdep to really have one mechanism. > > As the saying goes, it's hard to teach old dogs new tricks, but in the end > taking care of two dogs is likely harder than only a single dog? :) Or it's better to train a unmatured hunting dog than to teach a pet dog, how to hunt, for better hunting, even though the pet dog might eventually become able to. > I tend to favor (4) (or 3 with possible future work to achieve 4), but I am not > a locking maintainer, so really they have to voice what to do. Right. However, thanks for your opinion. > I do see value in DEPT (even if the folio lock might be handled differently). Thanks! Byungchul > > -- > Cheers, > > David

2 months, 1 week

[PATCH 0/2] Clear shared pages after private-to-shared conversion

by Steven Price

Arm CCA includes "Memory Encryption Contexts" (MEC) which allows the private and shared data accessible to a guest to have different memory encryption keys. Consequently when converting memory to shared, the memory encryption key used to access the physical page will change. Both the GICv3 ITS driver and the system_cc_shared dma-buf heap currently allocate memory with __GFP_ZERO and then decrypt it. With MEC the zeroing is done with the wrong encryption key and the data visible after decryption may be ciphertext. The RMM is required to scrub the data, but may perform this scrub with a different encryption key to the eventual key that will be used for shared access. Fix these two sites by avoiding the __GFP_ZERO during the allocation and performing a clear_pages() call after the decryption. Steven Price (2): irqchip/gic-v3-its: Zero shared pages after conversion dma-buf: heaps: Zero system shared heap pages after conversion drivers/dma-buf/heaps/system_heap.c | 14 +++++++++++--- drivers/irqchip/irq-gic-v3-its.c | 7 ++++++- 2 files changed, 17 insertions(+), 4 deletions(-) -- 2.43.0

2 months, 1 week

Re: [PATCH v2 09/15] accel/qda: Add DMA-backed GEM objects and memory manager integration

by Christian König

On 8/17/26 06:47, Ekansh Gupta wrote: > Introduce DMA-coherent buffer management for the QDA driver, wiring > together the GEM subsystem, the IOMMU memory manager, and a DMA > allocation backend. > > qda_gem.c / qda_gem.h > Implements the GEM object lifecycle for QDA buffers. Each buffer is > represented by a qda_gem_obj which embeds a drm_gem_object and > carries the kernel virtual address, DMA address, and a pointer to > the IOMMU device that performed the allocation. The .free callback > delegates to the memory manager, and the .mmap callback uses > dma_mmap_coherent() via the DMA backend. > > qda_memory_dma.c / qda_memory_dma.h > DMA coherent allocation backend. qda_dma_alloc() calls > dma_alloc_coherent() on the CB device and encodes the stream ID > (SID) in the upper 32 bits of the returned DMA address, following > the Qualcomm FastRPC convention for IOMMU address space tagging. > qda_dma_free() strips the SID prefix before calling > dma_free_coherent(). > > qda_memory_manager.c > Adds process-to-device assignment: each DRM file (process) is > assigned one IOMMU context bank device for the lifetime of the > session. qda_memory_manager_assign_device() first checks whether > the process already has a device (reusing it with a refcount > increment), then falls back to claiming an unassigned device. > qda_memory_manager_alloc() and qda_memory_manager_free() delegate > to the DMA backend after resolving the correct CB device for the > calling process. Oh, stuff like that is usually a pretty big NO-GO now. AMD has made the same mistake with KFD and it resulted in a massive chaos. The DRM file is the driver context your process uses and even if there are multiple DRM files for the same PID you should absolute *NOT* share anything between them. The general rule of thumb is to not attach anything to the process using the DRM file descriptor. Regards, Christian. > > qda_drv.c / qda_drv.h > qda_file_priv gains an assigned_iommu_dev pointer and a pid field. > The .postclose callback decrements the IOMMU device refcount and > clears the process assignment when the last reference is dropped. > > Assisted-by: Claude:claude-sonnet-5 > Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> > --- > Changes in v2: > - Adapt to the dynamically-sized device array introduced in patch 07 > (kcalloc'd from DT node count, replaces fixed QDA_IOMMU_DEVICES_MAX) > - Protect register/unregister with the process_assignment_lock mutex so > the device-assignment and device-registration paths are serialised > - No functional changes requested by reviewers on this patch > --- > drivers/accel/qda/Makefile | 2 + > drivers/accel/qda/qda_drv.c | 4 + > drivers/accel/qda/qda_drv.h | 4 + > drivers/accel/qda/qda_gem.c | 134 ++++++++++++++++++ > drivers/accel/qda/qda_gem.h | 52 +++++++ > drivers/accel/qda/qda_memory_dma.c | 82 +++++++++++ > drivers/accel/qda/qda_memory_dma.h | 17 +++ > drivers/accel/qda/qda_memory_manager.c | 239 ++++++++++++++++++++++++++++++++- > drivers/accel/qda/qda_memory_manager.h | 30 +++++ > 9 files changed, 559 insertions(+), 5 deletions(-) > > diff --git a/drivers/accel/qda/Makefile b/drivers/accel/qda/Makefile > index b658dad35fee..a46ddceecfc5 100644 > --- a/drivers/accel/qda/Makefile > +++ b/drivers/accel/qda/Makefile > @@ -8,7 +8,9 @@ obj-$(CONFIG_DRM_ACCEL_QDA) := qda.o > qda-y := \ > qda_cb.o \ > qda_drv.o \ > + qda_gem.o \ > qda_ioctl.o \ > + qda_memory_dma.o \ > qda_memory_manager.o \ > qda_rpmsg.o > > diff --git a/drivers/accel/qda/qda_drv.c b/drivers/accel/qda/qda_drv.c > index e1fd8bfa12d7..2b14dab95507 100644 > --- a/drivers/accel/qda/qda_drv.c > +++ b/drivers/accel/qda/qda_drv.c > @@ -21,6 +21,7 @@ static int qda_open(struct drm_device *dev, struct drm_file *file) > if (!qda_file_priv) > return -ENOMEM; > > + qda_file_priv->pid = current->pid; > qda_file_priv->qda_dev = qda_dev_from_drm(dev); > file->driver_priv = qda_file_priv; > > @@ -31,6 +32,9 @@ static void qda_postclose(struct drm_device *dev, struct drm_file *file) > { > struct qda_file_priv *qda_file_priv = file->driver_priv; > > + if (qda_file_priv->assigned_iommu_dev) > + qda_memory_manager_release_device(qda_file_priv->assigned_iommu_dev); > + > kfree(qda_file_priv); > file->driver_priv = NULL; > } > diff --git a/drivers/accel/qda/qda_drv.h b/drivers/accel/qda/qda_drv.h > index 690a833d732b..2fe58f3efec0 100644 > --- a/drivers/accel/qda/qda_drv.h > +++ b/drivers/accel/qda/qda_drv.h > @@ -24,6 +24,10 @@ > struct qda_file_priv { > /** @qda_dev: Back-pointer to device structure */ > struct qda_dev *qda_dev; > + /** @assigned_iommu_dev: IOMMU device assigned to this process */ > + struct qda_iommu_device *assigned_iommu_dev; > + /** @pid: Process ID for tracking */ > + pid_t pid; > }; > > /** > diff --git a/drivers/accel/qda/qda_gem.c b/drivers/accel/qda/qda_gem.c > new file mode 100644 > index 000000000000..66e78013a726 > --- /dev/null > +++ b/drivers/accel/qda/qda_gem.c > @@ -0,0 +1,134 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +// Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. > +#include <drm/drm_gem.h> > +#include <drm/drm_prime.h> > +#include <drm/drm_print.h> > +#include <linux/slab.h> > +#include <linux/dma-mapping.h> > +#include "qda_drv.h" > +#include "qda_gem.h" > +#include "qda_memory_manager.h" > +#include "qda_memory_dma.h" > + > +/** > + * qda_gem_free_object() - Free a GEM object and its associated resources > + * @gem_obj: DRM GEM object to free > + */ > +void qda_gem_free_object(struct drm_gem_object *gem_obj) > +{ > + struct qda_gem_obj *qda_gem_obj = to_qda_gem_obj(gem_obj); > + struct qda_dev *qdev = qda_dev_from_drm(gem_obj->dev); > + > + if (qda_gem_obj->virt && qdev->iommu_mgr) > + qda_memory_manager_free(qdev->iommu_mgr, qda_gem_obj); > + > + drm_gem_object_release(gem_obj); > + kfree(qda_gem_obj); > +} > + > +/** > + * qda_gem_mmap_obj() - Map a GEM object into userspace > + * @drm_obj: DRM GEM object to map > + * @vma: Virtual memory area to map into > + * > + * Return: 0 on success, negative error code on failure > + */ > +int qda_gem_mmap_obj(struct drm_gem_object *drm_obj, struct vm_area_struct *vma) > +{ > + struct qda_gem_obj *qda_gem_obj = to_qda_gem_obj(drm_obj); > + int ret; > + > + /* The fake offset is only used to find the object, not to index it */ > + vma->vm_pgoff = 0; > + > + ret = qda_dma_mmap(qda_gem_obj, vma); > + if (ret) > + return ret; > + > + vm_flags_set(vma, VM_DONTEXPAND | VM_DONTDUMP); > + > + return 0; > +} > + > +static const struct drm_gem_object_funcs qda_gem_object_funcs = { > + .free = qda_gem_free_object, > + .mmap = qda_gem_mmap_obj, > +}; > + > +/** > + * qda_gem_alloc_object() - Allocate a new QDA GEM object > + * @drm_dev: DRM device > + * @aligned_size: Size of the object in bytes (must be page-aligned) > + * > + * Return: Pointer to the new GEM object, or ERR_PTR on failure > + */ > +struct qda_gem_obj *qda_gem_alloc_object(struct drm_device *drm_dev, size_t aligned_size) > +{ > + struct qda_gem_obj *qda_gem_obj; > + int ret; > + > + qda_gem_obj = kzalloc_obj(*qda_gem_obj); > + if (!qda_gem_obj) > + return ERR_PTR(-ENOMEM); > + > + ret = drm_gem_object_init(drm_dev, &qda_gem_obj->base, aligned_size); > + if (ret) { > + kfree(qda_gem_obj); > + return ERR_PTR(ret); > + } > + > + qda_gem_obj->base.funcs = &qda_gem_object_funcs; > + qda_gem_obj->size = aligned_size; > + > + return qda_gem_obj; > +} > + > +void qda_gem_cleanup_object(struct qda_gem_obj *qda_gem_obj) > +{ > + drm_gem_object_release(&qda_gem_obj->base); > + kfree(qda_gem_obj); > +} > + > +int qda_gem_create_handle(struct drm_file *file_priv, struct drm_gem_object *gem_obj, u32 *handle) > +{ > + int ret; > + > + ret = drm_gem_handle_create(file_priv, gem_obj, handle); > + drm_gem_object_put(gem_obj); > + > + return ret; > +} > + > +/** > + * qda_gem_create_object() - Allocate and initialize a GEM object with DMA backing > + * @drm_dev: DRM device > + * @iommu_mgr: Memory manager to use for DMA allocation > + * @size: Requested size in bytes > + * @file_priv: DRM file private data for process association > + * > + * Return: Pointer to the base DRM GEM object on success, ERR_PTR on failure > + */ > +struct drm_gem_object *qda_gem_create_object(struct drm_device *drm_dev, > + struct qda_memory_manager *iommu_mgr, size_t size, > + struct drm_file *file_priv) > +{ > + struct qda_gem_obj *qda_gem_obj; > + size_t aligned_size; > + int ret; > + > + aligned_size = PAGE_ALIGN(size); > + if (!aligned_size) > + return ERR_PTR(-EINVAL); > + > + qda_gem_obj = qda_gem_alloc_object(drm_dev, aligned_size); > + if (IS_ERR(qda_gem_obj)) > + return ERR_CAST(qda_gem_obj); > + > + ret = qda_memory_manager_alloc(iommu_mgr, qda_gem_obj, file_priv); > + if (ret) { > + qda_gem_cleanup_object(qda_gem_obj); > + return ERR_PTR(ret); > + } > + > + return &qda_gem_obj->base; > +} > diff --git a/drivers/accel/qda/qda_gem.h b/drivers/accel/qda/qda_gem.h > new file mode 100644 > index 000000000000..afd7c9b49549 > --- /dev/null > +++ b/drivers/accel/qda/qda_gem.h > @@ -0,0 +1,52 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. > + */ > +#ifndef __QDA_GEM_H__ > +#define __QDA_GEM_H__ > + > +#include <linux/dma-mapping.h> > +#include <drm/drm_device.h> > +#include <drm/drm_gem.h> > +#include "qda_memory_manager.h" > + > +/** > + * struct qda_gem_obj - QDA GEM buffer object > + * > + * Represents a GEM buffer object that can be allocated by the driver > + * or imported from another driver via DMA-BUF. > + */ > +struct qda_gem_obj { > + /** @base: DRM GEM object base — must be first member */ > + struct drm_gem_object base; > + /** @iommu_dev: IOMMU context bank device that performed the allocation */ > + struct qda_iommu_device *iommu_dev; > + /** @virt: Kernel virtual address of the allocated DMA memory */ > + void *virt; > + /** @dma_addr: DMA address (with SID encoded in upper 32 bits) */ > + dma_addr_t dma_addr; > + /** @size: Size of the buffer in bytes */ > + size_t size; > +}; > + > +/** > + * to_qda_gem_obj - Cast a drm_gem_object pointer to qda_gem_obj > + * @gem_obj: Pointer to the embedded drm_gem_object > + */ > +#define to_qda_gem_obj(gem_obj) container_of(gem_obj, struct qda_gem_obj, base) > + > +/* GEM object lifecycle */ > +struct drm_gem_object *qda_gem_create_object(struct drm_device *drm_dev, > + struct qda_memory_manager *iommu_mgr, > + size_t size, struct drm_file *file_priv); > +void qda_gem_free_object(struct drm_gem_object *gem_obj); > +int qda_gem_mmap_obj(struct drm_gem_object *gem_obj, struct vm_area_struct *vma); > + > +/* Internal helpers (also used by PRIME import) */ > +struct qda_gem_obj *qda_gem_alloc_object(struct drm_device *drm_dev, size_t aligned_size); > +void qda_gem_cleanup_object(struct qda_gem_obj *qda_gem_obj); > + > +/* Utility functions */ > +int qda_gem_create_handle(struct drm_file *file_priv, struct drm_gem_object *gem_obj, u32 *handle); > + > +#endif /* __QDA_GEM_H__ */ > diff --git a/drivers/accel/qda/qda_memory_dma.c b/drivers/accel/qda/qda_memory_dma.c > new file mode 100644 > index 000000000000..7072ed8edf0b > --- /dev/null > +++ b/drivers/accel/qda/qda_memory_dma.c > @@ -0,0 +1,82 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +// Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. > +#include <linux/slab.h> > +#include <linux/dma-mapping.h> > +#include "qda_drv.h" > +#include "qda_gem.h" > +#include "qda_memory_dma.h" > + > +/* > + * The DSP identifies the IOMMU context bank from the upper bits of the address, > + * so the stream ID is folded into every address handed to it. The DMA API only > + * ever sees the plain 32-bit address, which is why the context bank devices are > + * created with a 32-bit DMA mask. > + */ > +static dma_addr_t get_actual_dma_addr(struct qda_gem_obj *gem_obj) > +{ > + return gem_obj->dma_addr - ((u64)gem_obj->iommu_dev->sid << 32); > +} > + > +static void setup_gem_object(struct qda_gem_obj *gem_obj, void *virt, > + dma_addr_t dma_addr, struct qda_iommu_device *iommu_dev) > +{ > + gem_obj->virt = virt; > + gem_obj->dma_addr = dma_addr; > + gem_obj->iommu_dev = iommu_dev; > +} > + > +static void cleanup_gem_object_fields(struct qda_gem_obj *gem_obj) > +{ > + gem_obj->virt = NULL; > + gem_obj->dma_addr = 0; > + gem_obj->iommu_dev = NULL; > +} > + > +/** > + * qda_dma_alloc() - Allocate DMA coherent memory for a GEM object > + * @iommu_dev: Pointer to the QDA IOMMU device structure > + * @gem_obj: Pointer to GEM object to allocate memory for > + * @size: Size of memory to allocate in bytes > + * > + * Return: 0 on success, negative error code on failure > + */ > +int qda_dma_alloc(struct qda_iommu_device *iommu_dev, > + struct qda_gem_obj *gem_obj, size_t size) > +{ > + dma_addr_t dma_addr; > + void *virt; > + > + virt = dma_alloc_coherent(iommu_dev->dev, size, &dma_addr, GFP_KERNEL); > + if (!virt) > + return -ENOMEM; > + > + dma_addr += ((u64)iommu_dev->sid << 32); > + setup_gem_object(gem_obj, virt, dma_addr, iommu_dev); > + > + return 0; > +} > + > +/** > + * qda_dma_free() - Free DMA coherent memory for a GEM object > + * @gem_obj: Pointer to GEM object to free memory for > + */ > +void qda_dma_free(struct qda_gem_obj *gem_obj) > +{ > + dma_free_coherent(gem_obj->iommu_dev->dev, gem_obj->size, > + gem_obj->virt, get_actual_dma_addr(gem_obj)); > + > + cleanup_gem_object_fields(gem_obj); > +} > + > +/** > + * qda_dma_mmap() - Map DMA memory into userspace > + * @gem_obj: Pointer to GEM object containing DMA memory > + * @vma: Virtual memory area to map into > + * > + * Return: 0 on success, negative error code on failure > + */ > +int qda_dma_mmap(struct qda_gem_obj *gem_obj, struct vm_area_struct *vma) > +{ > + return dma_mmap_coherent(gem_obj->iommu_dev->dev, vma, gem_obj->virt, > + get_actual_dma_addr(gem_obj), gem_obj->size); > +} > diff --git a/drivers/accel/qda/qda_memory_dma.h b/drivers/accel/qda/qda_memory_dma.h > new file mode 100644 > index 000000000000..99352a99dc33 > --- /dev/null > +++ b/drivers/accel/qda/qda_memory_dma.h > @@ -0,0 +1,17 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. > + */ > + > +#ifndef __QDA_MEMORY_DMA_H__ > +#define __QDA_MEMORY_DMA_H__ > + > +#include <linux/dma-mapping.h> > +#include "qda_memory_manager.h" > + > +int qda_dma_alloc(struct qda_iommu_device *iommu_dev, > + struct qda_gem_obj *gem_obj, size_t size); > +void qda_dma_free(struct qda_gem_obj *gem_obj); > +int qda_dma_mmap(struct qda_gem_obj *gem_obj, struct vm_area_struct *vma); > + > +#endif /* __QDA_MEMORY_DMA_H__ */ > diff --git a/drivers/accel/qda/qda_memory_manager.c b/drivers/accel/qda/qda_memory_manager.c > index b1a80ee77c35..d47c7419e11d 100644 > --- a/drivers/accel/qda/qda_memory_manager.c > +++ b/drivers/accel/qda/qda_memory_manager.c > @@ -1,14 +1,26 @@ > // SPDX-License-Identifier: GPL-2.0-only > // Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. > > +#include <linux/refcount.h> > #include <linux/slab.h> > +#include <linux/spinlock.h> > +#include <drm/drm_file.h> > +#include <drm/drm_print.h> > #include "qda_drv.h" > +#include "qda_gem.h" > #include "qda_memory_manager.h" > +#include "qda_memory_dma.h" > + > +static void iommu_device_free(struct kref *ref) > +{ > + kfree(container_of(ref, struct qda_iommu_device, ref)); > +} > > static void cleanup_all_memory_devices(struct qda_memory_manager *mem_mgr) > { > int i; > > + mutex_lock(&mem_mgr->process_assignment_lock); > for (i = 0; i < mem_mgr->num_devices; i++) { > struct qda_iommu_device *iommu_dev = mem_mgr->devices[i]; > > @@ -16,9 +28,215 @@ static void cleanup_all_memory_devices(struct qda_memory_manager *mem_mgr) > continue; > > mem_mgr->devices[i] = NULL; > - kfree(iommu_dev); > + kref_put(&iommu_dev->ref, iommu_device_free); > } > mem_mgr->num_devices = 0; > + mutex_unlock(&mem_mgr->process_assignment_lock); > +} > + > +static void init_iommu_device_fields(struct qda_iommu_device *iommu_dev) > +{ > + spin_lock_init(&iommu_dev->lock); > + refcount_set(&iommu_dev->users, 0); > + kref_init(&iommu_dev->ref); > + iommu_dev->assigned_pid = 0; > + iommu_dev->assigned_file_priv = NULL; > +} > + > +static struct qda_iommu_device *find_device_for_pid(struct qda_memory_manager *mem_mgr, > + pid_t pid) > +{ > + struct qda_iommu_device *found_dev = NULL; > + unsigned long flags; > + int i; > + > + for (i = 0; i < mem_mgr->num_devices; i++) { > + struct qda_iommu_device *iommu_dev = mem_mgr->devices[i]; > + > + if (!iommu_dev) > + continue; > + > + spin_lock_irqsave(&iommu_dev->lock, flags); > + if (iommu_dev->assigned_pid == pid) { > + found_dev = iommu_dev; > + refcount_inc(&found_dev->users); > + kref_get(&found_dev->ref); > + spin_unlock_irqrestore(&iommu_dev->lock, flags); > + break; > + } > + spin_unlock_irqrestore(&iommu_dev->lock, flags); > + } > + > + return found_dev; > +} > + > +static struct qda_iommu_device *assign_available_device_to_pid(struct qda_memory_manager *mem_mgr, > + pid_t pid, > + struct drm_file *file_priv) > +{ > + struct qda_iommu_device *selected_dev = NULL; > + unsigned long flags; > + int i; > + > + for (i = 0; i < mem_mgr->num_devices; i++) { > + struct qda_iommu_device *iommu_dev = mem_mgr->devices[i]; > + > + if (!iommu_dev) > + continue; > + > + spin_lock_irqsave(&iommu_dev->lock, flags); > + if (iommu_dev->assigned_pid == 0) { > + iommu_dev->assigned_pid = pid; > + iommu_dev->assigned_file_priv = file_priv; > + selected_dev = iommu_dev; > + refcount_set(&selected_dev->users, 1); > + kref_get(&selected_dev->ref); > + spin_unlock_irqrestore(&iommu_dev->lock, flags); > + break; > + } > + spin_unlock_irqrestore(&iommu_dev->lock, flags); > + } > + > + return selected_dev; > +} > + > +static struct qda_iommu_device *get_process_iommu_device(struct qda_memory_manager *mem_mgr, > + struct drm_file *file_priv) > +{ > + struct qda_file_priv *qda_priv; > + > + if (!file_priv || !file_priv->driver_priv) > + return NULL; > + > + qda_priv = (struct qda_file_priv *)file_priv->driver_priv; > + return qda_priv->assigned_iommu_dev; > +} > + > +/** > + * qda_memory_manager_assign_device() - Assign an IOMMU device to a process > + * @mem_mgr: Pointer to memory manager > + * @file_priv: DRM file private data for process association > + * > + * On success the caller owns a reference on the device and must release it > + * with qda_memory_manager_release_device(). > + * > + * Return: 0 on success, negative error code on failure > + */ > +int qda_memory_manager_assign_device(struct qda_memory_manager *mem_mgr, > + struct drm_file *file_priv) > +{ > + struct qda_file_priv *qda_priv; > + struct qda_iommu_device *selected_dev = NULL; > + int ret = 0; > + pid_t current_pid; > + > + if (!file_priv || !file_priv->driver_priv) > + return -EINVAL; > + > + qda_priv = (struct qda_file_priv *)file_priv->driver_priv; > + current_pid = qda_priv->pid; > + > + mutex_lock(&mem_mgr->process_assignment_lock); > + > + if (qda_priv->assigned_iommu_dev) { > + ret = 0; > + goto unlock_and_return; > + } > + > + selected_dev = find_device_for_pid(mem_mgr, current_pid); > + > + if (selected_dev) { > + qda_priv->assigned_iommu_dev = selected_dev; > + goto unlock_and_return; > + } > + > + selected_dev = assign_available_device_to_pid(mem_mgr, current_pid, file_priv); > + > + if (!selected_dev) { > + drm_dbg_driver(file_priv->minor->dev, "No context bank available for PID %d\n", > + current_pid); > + ret = -EBUSY; > + goto unlock_and_return; > + } > + > + qda_priv->assigned_iommu_dev = selected_dev; > + > +unlock_and_return: > + mutex_unlock(&mem_mgr->process_assignment_lock); > + > + return ret; > +} > + > +/** > + * qda_memory_manager_release_device() - Release a process assignment > + * @iommu_dev: Device previously obtained from qda_memory_manager_assign_device() > + * > + * Drops the caller's reference. Once the last process using the device is > + * gone the assignment is cleared so the device can serve another process. > + */ > +void qda_memory_manager_release_device(struct qda_iommu_device *iommu_dev) > +{ > + unsigned long flags; > + > + if (refcount_dec_and_test(&iommu_dev->users)) { > + spin_lock_irqsave(&iommu_dev->lock, flags); > + iommu_dev->assigned_pid = 0; > + iommu_dev->assigned_file_priv = NULL; > + spin_unlock_irqrestore(&iommu_dev->lock, flags); > + } > + > + kref_put(&iommu_dev->ref, iommu_device_free); > +} > + > +static struct qda_iommu_device *get_or_assign_iommu_device(struct qda_memory_manager *mem_mgr, > + struct drm_file *file_priv) > +{ > + struct qda_iommu_device *iommu_dev; > + int ret; > + > + iommu_dev = get_process_iommu_device(mem_mgr, file_priv); > + if (iommu_dev) > + return iommu_dev; > + > + ret = qda_memory_manager_assign_device(mem_mgr, file_priv); > + if (ret) > + return NULL; > + > + iommu_dev = get_process_iommu_device(mem_mgr, file_priv); > + if (iommu_dev) > + return iommu_dev; > + > + return NULL; > +} > + > +/** > + * qda_memory_manager_alloc() - Allocate memory for a GEM object > + * @mem_mgr: Pointer to memory manager > + * @gem_obj: Pointer to GEM object to allocate memory for > + * @file_priv: DRM file private data for process association > + * > + * Return: 0 on success, negative error code on failure > + */ > +int qda_memory_manager_alloc(struct qda_memory_manager *mem_mgr, struct qda_gem_obj *gem_obj, > + struct drm_file *file_priv) > +{ > + struct qda_iommu_device *selected_dev; > + > + selected_dev = get_or_assign_iommu_device(mem_mgr, file_priv); > + if (!selected_dev) > + return -EBUSY; > + > + return qda_dma_alloc(selected_dev, gem_obj, gem_obj->size); > +} > + > +/** > + * qda_memory_manager_free() - Free memory for a GEM object > + * @mem_mgr: Pointer to memory manager > + * @gem_obj: Pointer to GEM object to free memory for > + */ > +void qda_memory_manager_free(struct qda_memory_manager *mem_mgr, struct qda_gem_obj *gem_obj) > +{ > + qda_dma_free(gem_obj); > } > > /** > @@ -31,13 +249,21 @@ static void cleanup_all_memory_devices(struct qda_memory_manager *mem_mgr) > int qda_memory_manager_register_device(struct qda_memory_manager *mem_mgr, > struct qda_iommu_device *iommu_dev) > { > - if (mem_mgr->num_devices >= mem_mgr->max_devices) > - return -ENOSPC; > + int ret = 0; > > + mutex_lock(&mem_mgr->process_assignment_lock); > + if (mem_mgr->num_devices >= mem_mgr->max_devices) { > + ret = -ENOSPC; > + goto out; > + } > + > + init_iommu_device_fields(iommu_dev); > iommu_dev->id = mem_mgr->num_devices; > mem_mgr->devices[mem_mgr->num_devices++] = iommu_dev; > > - return 0; > +out: > + mutex_unlock(&mem_mgr->process_assignment_lock); > + return ret; > } > > /** > @@ -52,14 +278,16 @@ void qda_memory_manager_unregister_device(struct qda_memory_manager *mem_mgr, > { > int i; > > + mutex_lock(&mem_mgr->process_assignment_lock); > for (i = 0; i < mem_mgr->num_devices; i++) { > if (mem_mgr->devices[i] == iommu_dev) { > mem_mgr->devices[i] = NULL; > break; > } > } > + mutex_unlock(&mem_mgr->process_assignment_lock); > > - kfree(iommu_dev); > + kref_put(&iommu_dev->ref, iommu_device_free); > } > > /** > @@ -80,6 +308,7 @@ int qda_memory_manager_init(struct qda_memory_manager *mem_mgr, int max_devices) > > mem_mgr->num_devices = 0; > mem_mgr->max_devices = max_devices; > + mutex_init(&mem_mgr->process_assignment_lock); > > return 0; > } > diff --git a/drivers/accel/qda/qda_memory_manager.h b/drivers/accel/qda/qda_memory_manager.h > index 7e38c8a18284..0949c0c213f6 100644 > --- a/drivers/accel/qda/qda_memory_manager.h > +++ b/drivers/accel/qda/qda_memory_manager.h > @@ -7,25 +7,44 @@ > #define __QDA_MEMORY_MANAGER_H__ > > #include <linux/device.h> > +#include <linux/kref.h> > +#include <linux/mutex.h> > +#include <linux/refcount.h> > +#include <linux/spinlock.h> > +#include <drm/drm_file.h> > > /* Forward declarations */ > struct qda_dev; > +struct qda_gem_obj; > > /** > * struct qda_iommu_device - IOMMU device instance for memory management > * > * Represents a single IOMMU-enabled device managed by the memory manager. > * Each device can be assigned to a specific process session. > + * > + * The object outlives its registration: open files keep a reference through > + * @ref, so a device can be unregistered while a process still holds it. > */ > struct qda_iommu_device { > /** @dev: Pointer to the underlying device */ > struct device *dev; > /** @qdev: Back-pointer to the parent QDA device */ > struct qda_dev *qdev; > + /** @assigned_file_priv: DRM file private data for the assigned process */ > + struct drm_file *assigned_file_priv; > /** @id: Unique identifier assigned by the memory manager */ > u32 id; > /** @sid: Stream ID for IOMMU transactions */ > u32 sid; > + /** @assigned_pid: Process ID of the process assigned to this device */ > + pid_t assigned_pid; > + /** @users: Number of open files sharing this device */ > + refcount_t users; > + /** @ref: Reference count controlling when the object is freed */ > + struct kref ref; > + /** @lock: Spinlock protecting concurrent access to device */ > + spinlock_t lock; > }; > > /** > @@ -42,6 +61,8 @@ struct qda_memory_manager { > int num_devices; > /** @max_devices: Capacity of the @devices array */ > int max_devices; > + /** @process_assignment_lock: Mutex protecting process-to-device assignments */ > + struct mutex process_assignment_lock; > }; > > int qda_memory_manager_init(struct qda_memory_manager *mem_mgr, int max_devices); > @@ -51,5 +72,14 @@ int qda_memory_manager_register_device(struct qda_memory_manager *mem_mgr, > struct qda_iommu_device *iommu_dev); > void qda_memory_manager_unregister_device(struct qda_memory_manager *mem_mgr, > struct qda_iommu_device *iommu_dev); > +int qda_memory_manager_assign_device(struct qda_memory_manager *mem_mgr, > + struct drm_file *file_priv); > +void qda_memory_manager_release_device(struct qda_iommu_device *iommu_dev); > + > +int qda_memory_manager_alloc(struct qda_memory_manager *mem_mgr, > + struct qda_gem_obj *gem_obj, > + struct drm_file *file_priv); > +void qda_memory_manager_free(struct qda_memory_manager *mem_mgr, > + struct qda_gem_obj *gem_obj); > > #endif /* __QDA_MEMORY_MANAGER_H__ */ >

2 months, 1 week

Re: [PATCH v7 0/4] dma-buf: fix fd leak when copy_to_user() fails after fd_install()

by Christian König

I've gone ahead, added one more rb and pushed the result to drm-misc-fixes. Thanks for the help, Christian. On 8/17/26 07:04, Baineng Shou wrote: > Several drivers call dma_buf_fd() — which internally calls fd_install() > — before copy_to_user() returns the fd number to userspace. If > copy_to_user() fails, the fd is already published in the caller's fd > table but the ioctl returns an error, so userspace never learns the fd > number. Worse, the window between fd_install() and copy_to_user() > allows other threads to observe and manipulate the fd (dup, close, > SCM_RIGHTS), making any "close it on the failure path" fix unsafe. > > The fix is to split the allocation into three steps: reserve an fd with > get_unused_fd_flags() (not yet visible to other threads), do > copy_to_user(), and only then publish the fd with fd_install() via the > new dma_buf_fd_install() helper. On copy_to_user() failure, > put_unused_fd() + dma_buf_put() cleanly unwind with no user-visible > side effects. > > Patch 1 introduces dma_buf_fd_install() in dma-buf.c (wrapping > fd_install() together with the DMA_BUF_TRACE call to preserve export > tracing) and applies the fix to dma-heap. > > Patch 2 applies the same fix to fastrpc, which even had a comment > acknowledging the problem could not be fixed before. > > Patch 3 replaces the bare fd_install() in drm_gem_prime_handle_to_fd() > with dma_buf_fd_install() to restore tracepoint coverage for DRM PRIME > exports (suggested by Christian König). > > Patch 4 adds a selftest to tools/testing/selftests/dmabuf-heaps/ that > reproduces the fd-leak scenario (mprotect flip before the ioctl) and > verifies the fd count is unchanged after a failed ioctl (suggested by > Sumit Semwal). > > v1: https://lore.kernel.org/dri-devel/20260703080922.1838362-1-shoubaineng@gmai… > v2: https://lore.kernel.org/dri-devel/20260710105740.3080070-1-shoubaineng@gmai… > v3: https://lore.kernel.org/dri-devel/20260714114654.3885457-1-shoubaineng@gmai… > v5: https://lore.kernel.org/dri-devel/20260730062645.233148-1-shoubaineng@gmail… > v6: https://lore.kernel.org/dri-devel/20260807101140.1357218-1-shoubaineng@gmai… > > Changes in v7: > - Add Reviewed-by: T.J. Mercier to patch 4 (selftest). > - Add Acked-by: Sumit Semwal to the whole series. > > Changes in v6: > - Rework the selftest (patch 4) per review: extract a count_open_fds() > helper, fix the copy_from_user() comment, fail (not skip) when the > ioctl does not return -1, drop the bogus mprotect-race mention, and > reword the result message. > > Changes in v5: > - Add selftest (patch 4) reproducing the fd-leak scenario (Sumit Semwal) > > Changes in v4: > - Add patch 3: drm/prime: use dma_buf_fd_install() (Christian König) > - Add Acked-by: Christian König to patches 1 and 2 > > Changes in v3: > - Split into two patches (dma-heap + fastrpc separately) > - Add dma_buf_fd_install() to preserve trace_dma_buf_fd tracepoint > - Add fastrpc fix using the new helper (T.J. Mercier) > > Baineng Shou (4): > dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds > misc: fastrpc: don't publish fd before copy_to_user() succeeds > drm/prime: use dma_buf_fd_install() to preserve export tracing > selftests: dmabuf-heaps: add fd-leak-on-EFAULT regression test > > drivers/dma-buf/dma-buf.c | 20 ++++ > drivers/dma-buf/dma-heap.c | 80 ++++++------- > drivers/gpu/drm/drm_prime.c | 2 +- > drivers/misc/fastrpc.c | 16 +-- > include/linux/dma-buf.h | 1 + > .../selftests/dmabuf-heaps/dmabuf-heap.c | 113 +++++++++++++++++- > 6 files changed, 180 insertions(+), 52 deletions(-) >

2 months, 1 week

Re: [PATCH 2/2] drm/amdgpu/userq: hold the doorbell xa lock during hang reset

by Christian König

Hi, On 8/23/26 08:02, Junrui Luo wrote: > Hi Christian, Alex, > > Sorry for the ping. No need to look at the patch itself. > > I would just be grateful for a quick word on whether the issue it describes > is a real one. If not, I will drop it; if it is, should I send a v2? as far as I can see it is completely nonsense what you try to do here. The fence_drv references an amdgpu_userq object holds are the ones which the queue potentially waits on. When the queue is freed up those references must be dropped, but that shouldn't affect fence_drv->fences in any way possible. What exactly is the leak you are seeing? Regards, Christian. > > Thanks for your time, > Junrui Luo

2 months, 1 week

Re: [PATCH 0/2] fpga: add dma-buf based FPGA programming interface

by Christian König

On 8/16/26 17:07, Aravind Thokala wrote: > Some systems need to load large FPGA configuration images. The FPGA > subsystem allows loading images from the filesystem, but this requires > the entire image to be loaded into kernel memory first. For drivers > that need a DMA-capable buffer for programming, the data is then > copied again into DMA memory. This creates needless memory pressure > and delays due to the extra copy. > > This series adds dma-buf support that allows userspace to allocate a > buffer directly from a DMA heap, write the FPGA image into it, and > pass the file descriptor to the kernel via ioctl — skipping the > intermediate kernel buffer entirely. Well when you have a device with limited DMA capabilitiesthen DMA buf heaps doesn't allocate DMA-capable memory for that device either. So the explanation you give above why this interface might be useful is clearly not correct. The DMA subsystem will still do an additional copy when you try to import the DMA-buf allocated from the heap into this device. Either you need to define a heap with specific allocation restrictions (e.g. GFP_DMA32) or you allocate the DMA-buf through your fpga device so that dma_alloc_attrs() knows that a certain device needs to access the pages beforehand. Regards, Christian. > > Userspace flow: > 1. Allocate buffer from /dev/dma_heap/ (e.g., CMA heap) > 2. mmap the buffer and write the FPGA image into it > 3. ioctl(/dev/fpgaX, FPGA_IOCTL_LOAD_DMA_BUF, &dmabuf_fd) > > The dma-buf logic is implemented as a separate layer on top of the > FPGA manager, keeping buffer management separate from the write path. > Individual FPGA drivers opt in by calling fpga_dmabuf_register(). > --- > This work is based on the approach discussed in [1]. > > [1] https://lore.kernel.org/all/20231122053035.3758124-1-nava.kishore.manne@amd… > --- > Aravind Thokala (2): > fpga: Add dma-buf interface for FPGA programming > fpga: versal: add dma-buf programming support > > .../userspace-api/ioctl/ioctl-number.rst | 1 + > MAINTAINERS | 1 + > drivers/fpga/Kconfig | 9 + > drivers/fpga/Makefile | 2 + > drivers/fpga/fpga-dmabuf.c | 198 ++++++++++++++++++ > drivers/fpga/versal-fpga.c | 33 ++- > include/linux/fpga/fpga-dmabuf.h | 22 ++ > include/linux/fpga/fpga-mgr.h | 1 + > include/uapi/linux/fpga.h | 15 ++ > 9 files changed, 281 insertions(+), 1 deletion(-) > create mode 100644 drivers/fpga/fpga-dmabuf.c > create mode 100644 include/linux/fpga/fpga-dmabuf.h > create mode 100644 include/uapi/linux/fpga.h >

2 months, 1 week

Re: [PATCH v19 00/40] DEPT(DEPendency Tracker)

by Byungchul Park

On Thu, Aug 20, 2026 at 06:51:08PM +0100, Matthew Wilcox wrote: > On Thu, Aug 20, 2026 at 07:16:05PM +0200, David Hildenbrand (Arm) wrote: > > > Consider this real deadlock pattern that lockdep cannot detect: > > > > > > context X context Y context Z > > > > > > mutex_lock A > > > folio_lock B > > > folio_lock B <- DEADLOCK > > > mutex_lock A <- DEADLOCK > > > folio_unlock B > > > folio_unlock B > > > mutex_unlock A > > > mutex_unlock A > > > > But that really just boils down to folio lock being implemented as a PG_lock + > > some advanced wait mechanism. And we must do that because of lack of bits in > > struct page. > > > > Willy mentioned in a previous version [1]: "I don't think it makes sense to > > track lock state in the page (nor folio). Partly because there's just so many > > of them, but also because the locking rules don't really apply to individual > > folios so much as they do to the mappings (or anon_vmas) that contain folios." > > > > Given that lockdep is a debug feature, and we will at some point allocate struct > > folio separately, I assume we could just squeeze a "struct lockdep_map" in there > > in such debug configs and the world would not collapse. > > > > Doing that today (one "struct lockdep_map" in each "struct page") wouldn't work > > as mm_zero_struct_page() would not expect such large "struct page". But > > conceptually, for a debug kernel with a special CONFIG_LOCKDEP_PAGE_LOCK, maybe > > that would already be ok and we could just do that (and optimize it as we > > allocate folios separately). > > > > Not that it's ideal, but for a debug feature to at least check PG_lock, probably > > an easier way to achieve it than some completely new infrastructure. > > > > Now, Willy said "locking rules don't really apply to individual folios", I > > wonder if that could just help to also let lockdep check PG_lock with less > > metadata? (didn't fully wrap my head around the implications) > > > > [1] > > https://lore.kernel.org/all/aR3WHf9QZ_dizNun@casper.infradead.org/?utm_sour… > > There are a few things going on that make PG_lock special. Let me try > to explain again, only better this time. > > 1. The current lifetime of a struct page is the lifetime of the system. > But the semantics of its PG_lock bit change each time it is freed and > allocated. Yes, it's a classification issue that is very important. > 2. The position of PG_lock in the locking hierarchy only depend on > what the folio is currently being used for. That is, all folios in > a given xfs inode behave exactly the same from a locking perspective. You are exactly explaining what the classification means. Perfect. > There's no need to build up state about how each PG_lock is used; > they can all share. Arguably all xfs file inodes are the same as Right. That's why DEPT doesn't use a full map in each page but just uses a timestamp in each. For the classification, DEPT uses a few classes for folio, using global maps: 1. folios in mm paths 2. folios in block device buffer (meta data) 3. folios in regular file cache However, yes. I bet you could be a big help when classifying folios more presicely according to its usage. But the current classification is still a good start I think. > each other (directory inodes might be different from file inodes), > so we might want to go further than telling DEPT that "this folio > belongs to this inode" and go to "this folio belongs to this xfs file > inode". Totally agree. > 3. PG_lock can be taken in task context then released in interrupt > context. For full points, we need to mark the exact point at which > we submit the folio for read. Otherwise we can get into the situation > alluded to by f2c817bed58d and better discussed at > https://lore.kernel.org/linux-mm/20200127150024.GN1183@dhcp22.suse.cz/ > where we have the folio locked but haven't yet submitted it for I/O > so it doesn't matter how long we wait, it will never come unlocked. Interesting. The following abstraction might make DEPT work with it. For example: Annotate the point submitting IO as an event for the folio_lock() to be released. That way, the issue above can be detected by DEPT. Again, DEPT can do every thing we need w.r.t. deadlock. Byungchul

2 months, 1 week

Re: [PATCH v19 00/40] DEPT(DEPendency Tracker)

by Byungchul Park

On Thu, Aug 20, 2026 at 07:16:05PM +0200, David Hildenbrand (Arm) wrote: > On 7/6/26 08:18, Byungchul Park wrote: > > Hi Linus and folks, > > Hi, Hi, > I think there was plenty of feedback from locking maintainers in the past. One > question and a comment below. > > > > > DEPT(DEPendency Tracker) is a runtime deadlock detection framework that > > sees what lockdep cannot. > > > > I'm thrilled to share that DEPT has moved beyond theory and is now > > catching real deadlocks in the wild: > > > > https://lore.kernel.org/lkml/6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SA… > > https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.pa… > > https://lore.kernel.org/all/b6e00e77-4a8c-4e05-ab79-266bf05fcc2d@igalia.com/ > > > > I've added comprehensive documentation explaining DEPT's design and usage. > > Getting started is as simple as enabling CONFIG_DEPT and watching dmesg. > > > > THE PROBLEM LOCKDEP CANNOT SOLVE > > -------------------------------- > > > > Lockdep has been our trusted deadlock detector for two decades, but it > > has a fundamental blind spot: it tracks lock acquisition order, not the > > actual waits and events that cause deadlocks. This means lockdep misses: > > > > * Deadlocks involving folio locks (not released within the context) > > * Cross-context synchronization like wait_for_completion()/complete() > > * DMA fence waits, RCU waits, and general waitqueue patterns > > * Any synchronization primitive outside the classic lock/unlock model > > > > Consider this real deadlock pattern that lockdep cannot detect: > > > > context X context Y context Z > > > > mutex_lock A > > folio_lock B > > folio_lock B <- DEADLOCK > > mutex_lock A <- DEADLOCK > > folio_unlock B > > folio_unlock B > > mutex_unlock A > > mutex_unlock A > > But that really just boils down to folio lock being implemented as a PG_lock + > some advanced wait mechanism. And we must do that because of lack of bits in > struct page. > > Willy mentioned in a previous version [1]: "I don't think it makes sense to > track lock state in the page (nor folio). Partly because there's just so many > of them, but also because the locking rules don't really apply to individual > folios so much as they do to the mappings (or anon_vmas) that contain folios." Exactly. That's why we use classification e.g. lock class - DEPT also makes use of the concept. DEPT doesn't use a full map in each page but uses a minimum space for a timestamp in each to track when each starts to wait so as to use the recorded timestamp when the event occurs e.g. folio_unlock(). > Given that lockdep is a debug feature, and we will at some point allocate struct > folio separately, I assume we could just squeeze a "struct lockdep_map" in there > in such debug configs and the world would not collapse. That's a good news for lockdep. (And even for DEPT :) > Doing that today (one "struct lockdep_map" in each "struct page") wouldn't work > as mm_zero_struct_page() would not expect such large "struct page". But > conceptually, for a debug kernel with a special CONFIG_LOCKDEP_PAGE_LOCK, maybe > that would already be ok and we could just do that (and optimize it as we > allocate folios separately). Sounds great. > Not that it's ideal, but for a debug feature to at least check PG_lock, probably > an easier way to achieve it than some completely new infrastructure. I understand what you are going to tell. However, it's worth noting that lockdep tracks dependencies basically based on **lock acqusition orders** in the system. To make it track even rwlock and general synchronization mechanism as well, lockdep has no choice but to get more complicated. Focusing on only the dependency checking, the most parts of lockdep are for the tricky things, so the reusable parts are not that big. > Now, Willy said "locking rules don't really apply to individual folios", I > wonder if that could just help to also let lockdep check PG_lock with less > metadata? (didn't fully wrap my head around the implications) That's what DEPT did and what brought external wgen introduced in DEPT. I was considering the exactly same thing :) Again, lockdep that tracks lock acquisition orders can't do that. > [1] > https://lore.kernel.org/all/aR3WHf9QZ_dizNun@casper.infradead.org/?utm_sour… > > > It's your guiding example, that's why I mention it. You do mention other wait > cases here, I don't know anything about them, but for folios it's really just > "we used a single bit so far" AFAIKs. It doesn't matter whether it's implemented using bit or not. folio lock is quite special since it's allowed to be released other than the acquisition context that makes lockdep impossible to track them. > [...] > > > > > Q. Why not build DEPT into lockdep? > > > > A. Lockdep is stable, battle-tested code. I chose separation because > > while DEPT borrows BFS and hashing ideas, the wait/event model > > requires rebuilding from scratch. Lockdep was designed for lock > > acquisition order — retrofitting it would risk its stability. > > Why can't this just be some configurable extension to lockdep > (CONFIG_LOCKDEP_XYZ) until the feature is stable and can unconditionally be > enabled along with it? Answered? > I don't quite buy the "would risk its stability" argument. A lot of stuff we do > "risks stability", every day :) That's awsome anyway :) > Is there another good reason (incompatible with X, dangerous with Y, cinfusing > Z) why this really must be a separate thing? Roughly: 1. Similar or less effort is needed for the new one - retrofitting lockdep is not easy and big changes are required since the reusable parts are not that big. 2. Even though you didn't agree, retrofitting it would risk its stability. > > > > Q. Will DEPT replace lockdep? > > > > A. No. Lockdep validates correct lock usage — that's not going away. > > DEPT supersedes only the dependency-checking logic when mature. > > It's quite unfortunate that we'd end up with another similar-but-different > mechanism, that will just end up confusing people. I meant, at least dependency checking engine should be altered, but you make sense. Worth thinking it more. > But I am not a locking maintainer. I think there was plenty of discussion in the > past, so I might just be raising points that were already discussed in the past, > but I really just read some random pieces of earlier discussions. (ideally > previous discussions would be summarized here) > > Long story short: we are now in v19 and I think there was pushback in the past. > Did the opinion of locking maintainers change, or is there a way forward to > integrate this in a way that would make locking maintainers accept this? One of locking maintainers who I met in an LPC told me that he agrees with the direction of DEPT and supports DEPT, not officially tho. What he and other people are concerning w.r.t DEPT the most is, false positives, which is the most important issue for now. At the same time, I think the most important thing is to make DEPT useful in practice especially with folio locks involved. Actually, I'm planning to share DEPT's true reports periodically to LKML and work with people who believe DEPT can make things better. Any advices will be welcome. Thanks for your opinions. Byungchul > -- > Cheers, > > David

2 months, 1 week

[PATCH v2 0/4] Clear shared pages after private-to-shared conversion

by Steven Price

set_memory_decrypted() doesn't (currently) guarantee to preserve or zero memory, but both the GICv3 ITS driver and the system_cc_shared dma-buf heap currently allocate memory with __GFP_ZERO followed by calling set_memory_decrypted(). On an Arm CCA system with MEC this can cause ciphertext to be visible to the guest rather than the expected zeros. Patches 1 and 3 fix this by zeroing after the set_memory_decrypted() call. Patches 2 and 4 fix other related bugs that Sashiko found. Patch 2 fixes the issue that set_memory_decrypted() can be a sleeping call, so moves the allocation out of an atomic context. Patch 4 deals with the situation where set_memory_decrypted() fails and the rollback path could attempt to re-encrypt memory which was never decrypted. I've sorted the patches by area, but there's no (semantic) dependency between them. Changes in v2: * Switched to use BIT(n) rather than 1 << n in the GICv3 change. * Added Jason's R-b. * Patches 2 and 4 are new. v1: https://lore.kernel.org/r/20260820105026.53208-1-steven.price@arm.com Steven Price (4): irqchip/gic-v3-its: Zero shared pages after conversion irqchip/gic-v3-its: Allocate VPE tables from sleepable context dma-buf: heaps: Zero system shared heap pages after conversion dma-buf: heaps: Fix shared system heap allocation rollback drivers/dma-buf/heaps/system_heap.c | 24 +++++++++++++----- drivers/irqchip/irq-gic-v3-its.c | 39 ++++++++++++++++------------- 2 files changed, 40 insertions(+), 23 deletions(-) -- 2.43.0

2 months, 1 week

Re: [PATCH v2 03/15] accel/qda: Add initial QDA DRM accelerator driver

by Krzysztof Kozlowski

On 20/08/2026 12:07, Dmitry Baryshkov wrote: > On Thu, Aug 20, 2026 at 11:07:45AM +0200, Krzysztof Kozlowski wrote: >>>>>> >>>>>> Device node with this compatible is already populated, so this looks >>>>>> simply wrong or you are adding a duplicated driver. >>>>>> >>>>>> That's a no-go, you are supposed to work with existing drivers and grow >>>>>> them. >>>>> I'll bring the discussion again here, there was a discussion to move the >>>>> driver to accel subsystem if we want to support new features/uAPI >>>>> changes. Please read [1],[2] threads. The intention is to replace >>>>> fastrpc driver with QDA eventually. >>>> >>>> None of them address the problem. You want to grow fastrpc into user of >>>> dmabuf? So you move it from misc to here. >>> >>> It's not as easy and nice, so I think in this case it's better to repeat >> >> I disagree. The existing fastrpc driver is not that complicated. It's >> actually moderate amount of code, much less than Venus was (~7 times less). >> >> It easily can grow to support two interfaces and the only difficulty is >> how to manage these two interfaces simultaneously or exclusively, e.g. >> opening first one disables the second. > > I see the point here. > > Would it be acceptable if we add QDA support only on the new platforms > (e.g. via the SoC-specific compat), provide QDA for those platforms, > and, once it reaches complete API and feature parity, we remove the old > fastrpc driver, migrati old platforms. The problem with this approach is that we have no guarantees that it will reach feature parity in respect of old interface, thus old driver might stay forever. If we agree for duplicated driver, contributors have no incentives to support old approach. Much better is to refine the old driver, gradually adding new features while maintaining old stuff. This is the only way we can force contributors to actively work on minimizing duplicate parts. Best regards, Krzysztof

2 months, 2 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig