Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

19 participants
6395 discussions

Re: [PATCH 1/8] dma-heap: Add proper kref handling on dma-buf heaps

by Maxime Ripard

On Tue, May 05, 2026 at 06:40:21PM +0200, Boris Brezillon wrote: > On Tue, 5 May 2026 17:39:13 +0200 > Maxime Ripard <mripard(a)kernel.org> wrote: > > > Hi Boris, > > > > On Tue, May 05, 2026 at 05:20:48PM +0200, Boris Brezillon wrote: > > > Hi Ketil, > > > > > > On Tue, 5 May 2026 16:05:07 +0200 > > > Ketil Johnsen <ketil.johnsen(a)arm.com> wrote: > > > > > > > From: John Stultz <jstultz(a)google.com> > > > > > > > > Add proper reference counting on the dma_heap structure. While > > > > existing heaps are built-in, we may eventually have heaps loaded > > > > from modules, and we'll need to be able to properly handle the > > > > references to the heaps > > > > > > It's weird that this "heap as module" thing is mentioned here, but > > > actual robustness to make this safe is not added in the commit or any > > > of the following ones. > > > > > > > > > > > Signed-off-by: John Stultz <jstultz(a)google.com> > > > > Signed-off-by: T.J. Mercier <tjmercier(a)google.com> > > > > Signed-off-by: Yong Wu <yong.wu(a)mediatek.com> > > > > [Yong: Just add comment for "minor" and "refcount"] > > > > Signed-off-by: Yunfei Dong <yunfei.dong(a)mediatek.com> > > > > [Yunfei: Change reviewer's comments] > > > > Signed-off-by: Florent Tomasin <florent.tomasin(a)arm.com> > > > > [Florent: Rebase] > > > > Signed-off-by: Ketil Johnsen <ketil.johnsen(a)arm.com> > > > > [Ketil: Rebase] > > > > --- > > > > drivers/dma-buf/dma-heap.c | 29 +++++++++++++++++++++++++++++ > > > > include/linux/dma-heap.h | 2 ++ > > > > 2 files changed, 31 insertions(+) > > > > > > > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > > > > index ac5f8685a6494..9fd365ddbd517 100644 > > > > --- a/drivers/dma-buf/dma-heap.c > > > > +++ b/drivers/dma-buf/dma-heap.c > > > > @@ -12,6 +12,7 @@ > > > > #include <linux/dma-heap.h> > > > > #include <linux/err.h> > > > > #include <linux/export.h> > > > > +#include <linux/kref.h> > > > > #include <linux/list.h> > > > > #include <linux/nospec.h> > > > > #include <linux/syscalls.h> > > > > @@ -31,6 +32,7 @@ > > > > * @heap_devt: heap device node > > > > * @list: list head connecting to list of heaps > > > > * @heap_cdev: heap char device > > > > + * @refcount: reference counter for this heap device > > > > * > > > > * Represents a heap of memory from which buffers can be made. > > > > */ > > > > @@ -41,6 +43,7 @@ struct dma_heap { > > > > dev_t heap_devt; > > > > struct list_head list; > > > > struct cdev heap_cdev; > > > > + struct kref refcount; > > > > }; > > > > > > > > static LIST_HEAD(heap_list); > > > > @@ -248,6 +251,7 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > > > > if (!heap) > > > > return ERR_PTR(-ENOMEM); > > > > > > > > + kref_init(&heap->refcount); > > > > heap->name = exp_info->name; > > > > heap->ops = exp_info->ops; > > > > heap->priv = exp_info->priv; > > > > @@ -313,6 +317,31 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > > > > } > > > > EXPORT_SYMBOL_NS_GPL(dma_heap_add, "DMA_BUF_HEAP"); > > > > > > > > +static void dma_heap_release(struct kref *ref) > > > > +{ > > > > + struct dma_heap *heap = container_of(ref, struct dma_heap, refcount); > > > > + unsigned int minor = MINOR(heap->heap_devt); > > > > + > > > > + mutex_lock(&heap_list_lock); > > > > + list_del(&heap->list); > > > > + mutex_unlock(&heap_list_lock); > > > > + > > > > + device_destroy(dma_heap_class, heap->heap_devt); > > > > + cdev_del(&heap->heap_cdev); > > > > + xa_erase(&dma_heap_minors, minor); > > > > + > > > > + kfree(heap); > > > > > > That's actually problematic, because cdev_del() doesn't guarantee that > > > all opened FDs have been closed [1], it just guarantees that no new ones > > > can materialize. In order to make that safe, we'd need a > > > > > > 1. kref_get_unless_zero() in dma_heap_open(), with proper locking around > > > the xa_load() to protect against the heap removal that's happening > > > here > > > 2. a dma_heap_put() in a new dma_heap_close() implementation > > > 3. a guarantee that heap implementations won't go away until the last > > > ref is dropped, which means ops and all the data needed for this heap > > > to satisfy ioctl()s (and more generally every passed at > > > dma_heap_add() time) have to stay valid until the last ref is > > > dropped. Alternatively, we could restrict this only to in-flight > > > ioctl()s, and have the ops replaced by some dummy ops using RCU or a > > > rwlock. But I guess live dmabufs allocated on this heap have to > > > retain the heap and its implementation anyway. > > > > > > For record, #3 is already not satisfied by the current tee_heap > > > implementation (tee_dma_heap objects can vanish before the dma_heap > > > object is gone). The other implementations seem to be fine because they > > > are statically linked, and they either have exp_info.priv set to NULL, > > > or something that's never released. > > > > That statement won't hold for long, see: > > https://lore.kernel.org/r/20260427-dma-buf-heaps-as-modules-v5-0-b6f5678fee… > > > > However, all upstream heaps can be loaded as module, but not unloaded. > > So once you get a reference to it, you can assume it will live forever. > > That's why we didn't merge that patch before, even though it was discussed: > > > > https://lore.kernel.org/all/CANDhNCqk9Uk4aXHhUsL4hR1GHNmWZnH3C9Np-A02wdi+J3… > > Hm, not too sure that makes the tee_heap implementation sane WRT > tee_heap removal though, unless we have a guarantee that > tee_device_unregister() will never be called... I missed that part. You're totally right then :) Maxime

23 minutes

Demir Döner Merdivenler

by firmadan＠hotmail.com

Modern mimarinin vazgeçilmez yapı elemanlarından biri haline gelen demir döner merdivenler, hem estetik görünümü hem de uzun ömürlü kullanımıyla yaşam alanlarına değer katmaktadır. Özellikle dar alanlarda maksimum kullanım avantajı sunan bu merdiven sistemleri, evlerden iş yerlerine, dubleks dairelerden villa projelerine kadar birçok farklı alanda tercih edilmektedir. Dayanıklı metal yapısı sayesinde yüksek taşıma kapasitesine sahip olan demir döner merdiven modelleri, güvenli kullanım sunarken dekoratif tasarımlarıyla da dikkat çeker. Klasik, modern, endüstriyel veya minimalist dekorasyon stillerine uyum sağlayabilen bu özel merdivenler, mekânın atmosferini tamamen değiştirebilir. Demir döner merdivenlerin en önemli avantajlarından biri yer tasarrufu sağlamasıdır. Geleneksel düz merdivenlere göre daha az alan kaplayan spiral tasarım, özellikle küçük metrekareli alanlarda büyük avantaj sunar. Bu sayede hem kullanışlı hem de şık bir geçiş alanı oluşturulur. Üretim aşamasında kullanılan kaliteli demir malzeme, paslanmaya ve deformasyona karşı yüksek direnç sağlar. Elektrostatik boya uygulamaları sayesinde merdiven yüzeyi uzun yıllar ilk günkü görünümünü korur. İç mekân kullanımının yanı sıra dış mekân projelerinde de tercih edilen demir döner merdivenler, hava koşullarına dayanıklı yapısıyla güven verir. Kişiye özel ölçülerde üretilebilen modeller sayesinde her projeye uygun çözümler sunulabilir. Basamak genişliği, korkuluk tasarımı, renk seçenekleri ve merdiven çapı tamamen ihtiyaca göre şekillendirilebilir. Ahşap basamak detaylarıyla sıcak bir görünüm elde edilebilirken tamamen metal tasarımlarla modern ve güçlü bir atmosfer oluşturulabilir. Demir döner merdivenler sadece bir geçiş aracı değil, aynı zamanda dekoratif bir mimari unsur olarak da öne çıkar. Özellikle loft daireler, teras bağlantıları, çatı katları ve mağaza iç tasarımlarında estetik görünümüyle dikkat çekmektedir. Hem fonksiyonel hem de görsel açıdan güçlü bir çözüm arayanlar için ideal seçenekler arasında yer alır. Uzun ömürlü kullanım, sağlam yapı, estetik görünüm ve alan tasarrufu avantajlarını bir araya getiren demir döner merdiven sistemleri, modern yaşam alanlarının vazgeçilmez tercihleri arasında yer almaktadır. Siz de yaşam alanınıza özel tasarlanmış kaliteli ve şık bir merdiven çözümü ile mekânlarınıza değer katabilirsiniz. Demir döner merdiven https://fakrocatimerdivenleri.com/doner-merdivenler/

32 minutes

Fakro Çatı Merdivenleri

by firmadan＠hotmail.com

Fakro çatı merdivenleri, modern yaşam alanlarında çatı katına güvenli, konforlu ve pratik erişim sağlamak için geliştirilmiş yenilikçi çözümler arasında yer almaktadır. Dayanıklı yapısı, estetik tasarımı ve uzun ömürlü kullanım avantajı ile dikkat çeken Fakro çatı merdivenleri; evler, dubleks daireler, villalar, ofisler ve depo alanları için ideal bir kullanım sunar. Kullanılmadığı zaman katlanabilir yapısı sayesinde minimum alan kaplayan bu sistemler, yaşam alanlarında ekstra yer tasarrufu sağlamaktadır. Fakro’nun geliştirdiği çatı merdiveni modelleri; ahşap, metal ve makaslı sistem seçenekleriyle farklı ihtiyaçlara hitap eder. Isı yalıtımlı kapak yapıları sayesinde enerji kaybını minimum seviyeye indirirken, özellikle kış aylarında iç mekan sıcaklığının korunmasına yardımcı olur. Kaymaz basamak yapısı ve sağlam menteşe sistemi ise kullanıcı güvenliğini üst seviyeye taşır. Böylece hem güvenli hem de ergonomik bir kullanım deneyimi elde edilir. Kurulum açısından oldukça pratik olan Fakro çatı merdivenleri, tavan boşluklarına uyum sağlayan özel ölçü seçenekleri ile üretilmektedir. Tavana tam entegre olan yapısı sayesinde dekoratif açıdan da estetik bir görünüm sunar. Açılıp kapanma mekanizmasının kolay çalışması, günlük kullanım sırasında büyük avantaj sağlar. Özellikle dar alanlarda maksimum verim almak isteyen kullanıcılar için son derece işlevsel bir çözüm oluşturur. Fakro ahşap çatı merdivenleri doğal görünümü ile yaşam alanlarına sıcak bir atmosfer kazandırırken, metal çatı merdivenleri yüksek taşıma kapasitesi ve dayanıklılığı ile öne çıkar. Makaslı alüminyum modeller ise kompakt yapıları sayesinde küçük tavan girişlerinde bile rahat kullanım imkanı sunmaktadır. Her modelde kalite standartlarının yüksek tutulması, ürünlerin uzun yıllar sorunsuz kullanılmasına katkı sağlar. Fakro çatı merdivenleri https://www.fakrocatimerdivenleri.com

33 minutes

Re: [PATCH] accel/ivpu: Reject PRIME export of userptr BOs

by Christian König

Hi Zivi, On 5/8/26 18:28, Ziyi Guo wrote: > Userptr BOs wrap pinned user pages in a private dma-buf solely for > internal use by the NPU driver. Allowing userspace to re-export such a > BO via DRM_IOCTL_PRIME_HANDLE_TO_FD would expose those pages to other > drivers through an interface that was never intended to be shared. > > Override the driver's prime_handle_to_fd callback to detect dma-bufs > backed by ivpu_gem_userptr_dmabuf_ops and reject the export with > -EINVAL. > > Signed-off-by: Ziyi Guo <n7l8m4(a)u.northwestern.edu> first of all thanks a lot for pointing that out! The patch which orginally added that somehow slipped through the cracks. Then @Karol and @Jacek, using DMA-buf like that is a pretty big NO-GO from the DMA-buf side! Using page which you don't own (especially file system backend ones) in a DMA-buf is absolutely *NOT* something you can do. I hope that it is not the case here, but if you also allow to mmap() them then you have create a massive security problem which can lead to random file system corruptions. Regards, Christian. > --- > drivers/accel/ivpu/ivpu_drv.c | 1 + > drivers/accel/ivpu/ivpu_gem.c | 28 +++++++++++++++++++++++++++ > drivers/accel/ivpu/ivpu_gem.h | 3 +++ > drivers/accel/ivpu/ivpu_gem_userptr.c | 5 +++++ > 4 files changed, 37 insertions(+) > > diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c > index 2801378e3e19..086d4c769b33 100644 > --- a/drivers/accel/ivpu/ivpu_drv.c > +++ b/drivers/accel/ivpu/ivpu_drv.c > @@ -545,6 +545,7 @@ static const struct drm_driver driver = { > > .gem_create_object = ivpu_gem_create_object, > .gem_prime_import = ivpu_gem_prime_import, > + .prime_handle_to_fd = ivpu_gem_prime_handle_to_fd, > > .ioctls = ivpu_drm_ioctls, > .num_ioctls = ARRAY_SIZE(ivpu_drm_ioctls), > diff --git a/drivers/accel/ivpu/ivpu_gem.c b/drivers/accel/ivpu/ivpu_gem.c > index 4f2005a8d496..82079f372b39 100644 > --- a/drivers/accel/ivpu/ivpu_gem.c > +++ b/drivers/accel/ivpu/ivpu_gem.c > @@ -12,6 +12,7 @@ > #include <drm/drm_cache.h> > #include <drm/drm_debugfs.h> > #include <drm/drm_file.h> > +#include <drm/drm_prime.h> > #include <drm/drm_utils.h> > > #include "ivpu_drv.h" > @@ -249,6 +250,33 @@ struct drm_gem_object *ivpu_gem_prime_import(struct drm_device *dev, > return ERR_PTR(ret); > } > > +int ivpu_gem_prime_handle_to_fd(struct drm_device *dev, struct drm_file *file_priv, > + u32 handle, u32 flags, int *prime_fd) > +{ > + struct ivpu_device *vdev = to_ivpu_device(dev); > + struct dma_buf *dmabuf; > + int fd; > + > + dmabuf = drm_gem_prime_handle_to_dmabuf(dev, file_priv, handle, flags); > + if (IS_ERR(dmabuf)) > + return PTR_ERR(dmabuf); > + > + if (ivpu_gem_is_userptr_dma_buf(dmabuf)) { > + ivpu_dbg(vdev, IOCTL, "Exporting userptr BO is not allowed\n"); > + dma_buf_put(dmabuf); > + return -EINVAL; > + } > + > + fd = dma_buf_fd(dmabuf, flags); > + if (fd < 0) { > + dma_buf_put(dmabuf); > + return fd; > + } > + > + *prime_fd = fd; > + return 0; > +} > + > static struct ivpu_bo *ivpu_bo_alloc(struct ivpu_device *vdev, u64 size, u32 flags) > { > struct drm_gem_shmem_object *shmem; > diff --git a/drivers/accel/ivpu/ivpu_gem.h b/drivers/accel/ivpu/ivpu_gem.h > index 0c3350f22b55..bfd15ce02354 100644 > --- a/drivers/accel/ivpu/ivpu_gem.h > +++ b/drivers/accel/ivpu/ivpu_gem.h > @@ -29,6 +29,9 @@ void ivpu_bo_unbind_all_bos_from_context(struct ivpu_device *vdev, struct ivpu_m > > struct drm_gem_object *ivpu_gem_create_object(struct drm_device *dev, size_t size); > struct drm_gem_object *ivpu_gem_prime_import(struct drm_device *dev, struct dma_buf *dma_buf); > +int ivpu_gem_prime_handle_to_fd(struct drm_device *dev, struct drm_file *file_priv, > + u32 handle, u32 flags, int *prime_fd); > +bool ivpu_gem_is_userptr_dma_buf(struct dma_buf *dma_buf); > struct ivpu_bo *ivpu_bo_create(struct ivpu_device *vdev, struct ivpu_mmu_context *ctx, > struct ivpu_addr_range *range, u64 size, u32 flags); > struct ivpu_bo *ivpu_bo_create_runtime(struct ivpu_device *vdev, u64 addr, u64 size, u32 flags); > diff --git a/drivers/accel/ivpu/ivpu_gem_userptr.c b/drivers/accel/ivpu/ivpu_gem_userptr.c > index 7cbf3a4cdc73..45eabea5961e 100644 > --- a/drivers/accel/ivpu/ivpu_gem_userptr.c > +++ b/drivers/accel/ivpu/ivpu_gem_userptr.c > @@ -61,6 +61,11 @@ static const struct dma_buf_ops ivpu_gem_userptr_dmabuf_ops = { > .release = ivpu_gem_userptr_dmabuf_release, > }; > > +bool ivpu_gem_is_userptr_dma_buf(struct dma_buf *dma_buf) > +{ > + return dma_buf->ops == &ivpu_gem_userptr_dmabuf_ops; > +} > + > static struct dma_buf * > ivpu_create_userptr_dmabuf(struct ivpu_device *vdev, void __user *user_ptr, > size_t size, uint32_t flags) > -- > 2.34.1 >

58 minutes

Top 10 Verified Recovery Firms Available Hire Primatz Guard

by harperquinn708＠gmail.com

Primatz Guard helps victims of crypto, romance, and investment scams trace funds, investigate fraud, and seek recovery with transparent consultation support.

4 days, 10 hours

Re: [PATCH 1/9] vfio/pci: Fix vfio_pci_dma_buf_cleanup() double-put

by Leon Romanovsky

On Wed, May 06, 2026 at 04:55:27PM +0100, Matt Evans wrote: > Hi Leon, > > On 06/05/2026 16:29, Leon Romanovsky wrote: > > > > On Wed, May 06, 2026 at 02:53:31PM +0100, Matt Evans wrote: > > > Hi Alex, > > > > > > On 01/05/2026 20:12, Alex Williamson wrote: > > > > > > > > On Thu, 16 Apr 2026 06:17:44 -0700 > > > > Matt Evans <mattev(a)meta.com> wrote: > > > > > > > > > vfio_pci_dma_buf_cleanup() assumed all VFIO device DMABUFs need to be > > > > > revoked. However, if vfio_pci_dma_buf_move() revokes DMABUFs before > > > > > the fd/device closes, then vfio_pci_dma_buf_cleanup() would do a > > > > > second/underflowing kref_put() then wait_for_completion() on a > > > > > completion that never fires. Fixed by predicating on revocation > > > > > status. > > > > > > > > > > This could happen if PCI_COMMAND_MEMORY is cleared before closing the > > > > > device fd (but the scenario is more likely to hit when future commits > > > > > add more methods to revoke DMABUFs). > > > > > > > > > > Fixes: 1a8a5227f2299 ("vfio: Wait for dma-buf invalidation to complete") > > > > > Signed-off-by: Matt Evans <mattev(a)meta.com> > > > > > --- > > > > > > > > > > (Just a fix, but later "vfio/pci: Convert BAR mmap() to use a DMABUF" > > > > > and "vfio/pci: Permanently revoke a DMABUF on request" depend on this > > > > > context, so including in this series.) > > > > > > > > We really need a fix for this split out from this series, It's already > > > > been shown[1] that this is trivially reachable. Carlos proposed[2] a > > > > similar solution to the one below. I was concurrently working on the > > > > issued and suggested an alternative[3]. Let's pick a solution for > > > > 7.1-rc. Thanks, > > > > > > It looks like [3] is progressing, so I'll drop this one when I can rebase > > > onto it. > > > > > > I noticed [3] removes the dma_resv_lock(priv->dmabuf->resv) around the > > > priv->vdev = NULL, and this series' vfio_pci_mmap_huge_fault() relies on > > > vdev only changing whilst resv is held to resolve a race between a fault and > > > cleanup (see patch 7 of this series). The handler takes resv so that it can > > > stably test vdev in order to take memory_lock. > > > > I think that you should rely on priv->revoked and not on priv->vdev. > > Needs both unfortunately, as the fault handler ultimately needs to take > vdev->memory_lock. One can argue that if priv->revoked == True, all accesses to device should be denied and treated as priv->vdev == Null. Thanks

4 days, 16 hours

Re: [PATCH 0/4] Let userspace explicitly trigger memory reclaims

by Steven Price

On 06/05/2026 11:45, Nicolas Frattaroli wrote: > RAM is not, in fact, cheap. Especially on embedded systems with a low > amount of memory, but known and well-defined userspace, more explicit > resource management can lead to better utilisation patterns. As an > example, a resource manager process on a purpose-built device may wish > to launch, and then explicitly swap out, memory of processes that are > kept "warm", to improve perceived startup latency of individual > full-screen applications without making the kernel figure out the usage > pattern from observation alone in order to swap out the right pages. Have you considered memory control groups (memcg) for this purpose? Imposing a lower limit than currently allocated should trigger reclaim, so 'background' applications could have the limit lowered and then restored when moved to the foreground. > To allow for this explicit control in the context of panthor's GPU > memory, add two new sysfs knobs. The first, mem_reclaim, runs an > explicit priv BO reclaim cycle on the TGID written to it. > > The second, mem_claim, does the opposite: it swaps BOs back into active > memory. How necessary is this mem_claim for performance? Have you done any benchmarking of explicitly claiming vs just allowing it to happen naturally? My gut feeling is that mem_claim should be unnecessary in most situations, but I'm prepared to be proved wrong. I'm not saying this series is necessarily the wrong approach - but I think we need a bit more justification for adding a new API for this. Thanks, Steve > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli(a)collabora.com> > --- > Nicolas Frattaroli (4): > drm/panthor: Add freed_sz parameter to reclaim_priv_bos > MAINTAINERS: Add sysfs ABI docs to list of panthor files > drm/panthor: Add explicit memory reclaim sysfs knob > drm/panthor: Add explicit memory claim sysfs knob > > Documentation/ABI/testing/sysfs-driver-panthor-mem | 34 ++++++++ > MAINTAINERS | 1 + > drivers/gpu/drm/panthor/panthor_drv.c | 93 ++++++++++++++++++++++ > drivers/gpu/drm/panthor/panthor_gem.c | 7 +- > drivers/gpu/drm/panthor/panthor_gem.h | 1 + > drivers/gpu/drm/panthor/panthor_mmu.c | 70 +++++++++++++++- > drivers/gpu/drm/panthor/panthor_mmu.h | 4 + > 7 files changed, 205 insertions(+), 5 deletions(-) > --- > base-commit: 2c4b906cd135bbb44855287d0d0eff0ee0b47afe > change-id: 20260506-panthor-explicit-reclaim-3dffed028d8c > > Best regards, > -- > Nicolas Frattaroli <nicolas.frattaroli(a)collabora.com> >

4 days, 16 hours

Re: [PATCH 1/9] vfio/pci: Fix vfio_pci_dma_buf_cleanup() double-put

by Leon Romanovsky

On Wed, May 06, 2026 at 02:53:31PM +0100, Matt Evans wrote: > Hi Alex, > > On 01/05/2026 20:12, Alex Williamson wrote: > > > > On Thu, 16 Apr 2026 06:17:44 -0700 > > Matt Evans <mattev(a)meta.com> wrote: > > > > > vfio_pci_dma_buf_cleanup() assumed all VFIO device DMABUFs need to be > > > revoked. However, if vfio_pci_dma_buf_move() revokes DMABUFs before > > > the fd/device closes, then vfio_pci_dma_buf_cleanup() would do a > > > second/underflowing kref_put() then wait_for_completion() on a > > > completion that never fires. Fixed by predicating on revocation > > > status. > > > > > > This could happen if PCI_COMMAND_MEMORY is cleared before closing the > > > device fd (but the scenario is more likely to hit when future commits > > > add more methods to revoke DMABUFs). > > > > > > Fixes: 1a8a5227f2299 ("vfio: Wait for dma-buf invalidation to complete") > > > Signed-off-by: Matt Evans <mattev(a)meta.com> > > > --- > > > > > > (Just a fix, but later "vfio/pci: Convert BAR mmap() to use a DMABUF" > > > and "vfio/pci: Permanently revoke a DMABUF on request" depend on this > > > context, so including in this series.) > > > > We really need a fix for this split out from this series, It's already > > been shown[1] that this is trivially reachable. Carlos proposed[2] a > > similar solution to the one below. I was concurrently working on the > > issued and suggested an alternative[3]. Let's pick a solution for > > 7.1-rc. Thanks, > > It looks like [3] is progressing, so I'll drop this one when I can rebase > onto it. > > I noticed [3] removes the dma_resv_lock(priv->dmabuf->resv) around the > priv->vdev = NULL, and this series' vfio_pci_mmap_huge_fault() relies on > vdev only changing whilst resv is held to resolve a race between a fault and > cleanup (see patch 7 of this series). The handler takes resv so that it can > stably test vdev in order to take memory_lock. I think that you should rely on priv->revoked and not on priv->vdev. Thanks > > Must your fix change vdev outside of holding resv? I'm still sketching > alternatives; at first glance perhaps the fault handler could rely on vdev > being valid if !revoked, which can be tested holding [only] resv. > > > Thanks, > > Matt > > > > > Alex > > > > [1]https://lore.kernel.org/all/GVXPR02MB12019AA6014F27EF5D773E89BFB372@GVXPR… > > [2]https://lore.kernel.org/all/20260429182736.409323-2-clopez@suse.de/ > > [3]https://lore.kernel.org/all/20260429142242.70f746b4@nvidia.com/ > > > > > drivers/vfio/pci/vfio_pci_dmabuf.c | 9 +++++++-- > > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c > > > index 281ba7d69567..04478b7415a0 100644 > > > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c > > > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c > > > @@ -395,20 +395,25 @@ void vfio_pci_dma_buf_cleanup(struct vfio_pci_core_device *vdev) > > > down_write(&vdev->memory_lock); > > > list_for_each_entry_safe(priv, tmp, &vdev->dmabufs, dmabufs_elm) { > > > + bool was_revoked; > > > + > > > if (!get_file_active(&priv->dmabuf->file)) > > > continue; > > > dma_resv_lock(priv->dmabuf->resv, NULL); > > > list_del_init(&priv->dmabufs_elm); > > > priv->vdev = NULL; > > > + was_revoked = priv->revoked; > > > priv->revoked = true; > > > dma_buf_invalidate_mappings(priv->dmabuf); > > > dma_resv_wait_timeout(priv->dmabuf->resv, > > > DMA_RESV_USAGE_BOOKKEEP, false, > > > MAX_SCHEDULE_TIMEOUT); > > > dma_resv_unlock(priv->dmabuf->resv); > > > - kref_put(&priv->kref, vfio_pci_dma_buf_done); > > > - wait_for_completion(&priv->comp); > > > + if (!was_revoked) { > > > + kref_put(&priv->kref, vfio_pci_dma_buf_done); > > > + wait_for_completion(&priv->comp); > > > + } > > > vfio_device_put_registration(&vdev->vdev); > > > fput(priv->dmabuf->file); > > > } > > >

4 days, 17 hours

Re: [PATCH 1/4] drm/panthor: Add freed_sz parameter to reclaim_priv_bos

by Steven Price

On 06/05/2026 11:45, Nicolas Frattaroli wrote: > panthor_mmu_reclaim_priv_bos returns the number of freed pages. However, > how many bytes of freed memory this translates to can't generally be > deduced from the number of pages, as the page size is a per-VM property. > > It may be useful to know the exact number of bytes that have been freed The "useful" aspect seems to just be a drm_dbg() message from what I can see with this series? Am I missing something or is it not actually that useful? Thanks, Steve > for observability and debugging purposes. To that end, add a new > parameter "freed_sz", which is a pointer to a size_t where this > information will be stored. It may be NULL, in which case the > information isn't stored at all. > > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli(a)collabora.com> > --- > drivers/gpu/drm/panthor/panthor_gem.c | 3 ++- > drivers/gpu/drm/panthor/panthor_mmu.c | 12 ++++++++++-- > drivers/gpu/drm/panthor/panthor_mmu.h | 1 + > 3 files changed, 13 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c > index 13295d7a593d..80e82238f3c5 100644 > --- a/drivers/gpu/drm/panthor/panthor_gem.c > +++ b/drivers/gpu/drm/panthor/panthor_gem.c > @@ -1511,7 +1511,8 @@ panthor_gem_shrinker_scan(struct shrinker *shrinker, struct shrink_control *sc) > goto out; > > freed += panthor_mmu_reclaim_priv_bos(ptdev, sc->nr_to_scan - freed, > - &remaining, panthor_gem_try_evict); > + &remaining, NULL, > + panthor_gem_try_evict); > if (freed >= sc->nr_to_scan) > goto out; > > diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c > index a7ee14986849..b81388b35a58 100644 > --- a/drivers/gpu/drm/panthor/panthor_mmu.c > +++ b/drivers/gpu/drm/panthor/panthor_mmu.c > @@ -3127,13 +3127,18 @@ int panthor_vm_prepare_mapped_bos_resvs(struct drm_exec *exec, struct panthor_vm > unsigned long > panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev, > unsigned int nr_to_scan, unsigned long *remaining, > + size_t *freed_sz, > bool (*shrink)(struct drm_gem_object *, > struct ww_acquire_ctx *)) > { > + unsigned long newly_freed; > unsigned long freed = 0; > LIST_HEAD(remaining_vms); > LIST_HEAD(vms); > > + if (freed_sz) > + *freed_sz = 0; > + > mutex_lock(&ptdev->reclaim.lock); > list_splice_init(&ptdev->reclaim.vms, &vms); > > @@ -3152,8 +3157,11 @@ panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev, > > mutex_unlock(&ptdev->reclaim.lock); > > - freed += drm_gem_lru_scan(&vm->reclaim.lru, nr_to_scan - freed, > - remaining, shrink, NULL); > + newly_freed = drm_gem_lru_scan(&vm->reclaim.lru, nr_to_scan - freed, > + remaining, shrink, NULL); > + if (freed_sz) > + *freed_sz += panthor_vm_page_size(vm) * newly_freed; > + freed += newly_freed; > > mutex_lock(&ptdev->reclaim.lock); > > diff --git a/drivers/gpu/drm/panthor/panthor_mmu.h b/drivers/gpu/drm/panthor/panthor_mmu.h > index 3522fbbce369..12b18b5f90e1 100644 > --- a/drivers/gpu/drm/panthor/panthor_mmu.h > +++ b/drivers/gpu/drm/panthor/panthor_mmu.h > @@ -52,6 +52,7 @@ int panthor_vm_evict_bo_mappings_locked(struct panthor_gem_object *bo); > unsigned long > panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev, > unsigned int nr_to_scan, unsigned long *remaining, > + size_t *freed_sz, > bool (*shrink)(struct drm_gem_object *, > struct ww_acquire_ctx *)); > int panthor_vm_prepare_mapped_bos_resvs(struct drm_exec *exec, >

4 days, 17 hours

Re: [PATCH 6/8] drm/panthor: Explicit expansion of locked VM region

by Nicolas Frattaroli

On Tuesday, 5 May 2026 16:05:12 Central European Summer Time Ketil Johnsen wrote: > Currently the panthor_vm_lock_region() function will implicitly expand > an already locked VM region. This can be problematic because the caller > do not reliably know if it needs to call panthor_vm_unlock_region() > or not. > > Worth noting, there is currently no known issues with this as the code > is written today. > > This change introduces panthor_vm_expand_region() which will only work > if there is already a locked VM region. This again means that the > original lock and unlock functions can work as a pair. This pairing is > needed for subsequent protected memory changes. > > Signed-off-by: Ketil Johnsen <ketil.johnsen(a)arm.com> > --- > drivers/gpu/drm/panthor/panthor_mmu.c | 69 +++++++++++++++++++-------- > 1 file changed, 50 insertions(+), 19 deletions(-) > While trying this series, I attempted my usual `modprobe -r panthor && modprobe panthor protected_heap_name=default_cma_region`. Unfortunately, it oopses when attempting to unmap the sg for a bo labeled "FW section" on panthor module unload, and I bisected it to this patch. The oops: [ 598.515550] Unable to handle kernel paging request at virtual address 0000000000400267 [ 598.516864] Mem abort info: [ 598.517676] ESR = 0x0000000096000004 [ 598.518560] EC = 0x25: DABT (current EL), IL = 32 bits [ 598.520414] SET = 0, FnV = 0 [ 598.521275] EA = 0, S1PTW = 0 [ 598.522099] FSC = 0x04: level 0 translation fault [ 598.523069] Data abort info: [ 598.524311] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 598.525566] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 598.526850] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 598.527905] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104056000 [ 598.529019] [0000000000400267] pgd=0000000000000000, p4d=0000000000000000 [ 598.530170] Internal error: Oops: 0000000096000004 [#1] SMP [ 598.531158] Modules linked in: btusb btrtl btmtk btintel btbcm bluetooth ecdh_generic ecc kpp snd_soc_hdmi_codec cfg80211 r8169 rfkill_gpio pwm_fan rfkill snd_soc_es8316 rtc_hym8563 rk805_pwrkey at24 fusb302 tcpm aux_hpd_bridge display_connector snd_soc_simple_card phy_rockchip_samsung_hdptx phy_rockchip_usbdp rockchip_thermal typec phy_rockchip_naneng_combphy rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchipdrm inno_hdmi dw_dp hantro_vpu rockchip_vdec dw_mipi_dsi2 v4l2_jpeg v4l2_vp9 rockchip_rga dw_mipi_dsi v4l2_h264 synopsys_hdmirx v4l2_dv_timings spi_rockchip_sfc videobuf2_dma_contig videobuf2_dma_sg v4l2_mem2mem videobuf2_memops dw_hdmi_qp onboard_usb_dev analogix_dp videobuf2_v4l2 videobuf2_common snd_soc_rockchip_i2s_tdm dw_hdmi videodev mc drm_display_helper nvme cec panthor(-) drm_gpuvm drm_exec gpu_sched drm_dp_aux_bus drm_dma_helper drm_client_lib nvme_core drm_kms_helper drm pci_endpoint_test backlight snd_soc_audio_graph_card snd_soc_simple_card_utils fuse dm_mod [ 598.541237] CPU: 6 UID: 0 PID: 806 Comm: modprobe Not tainted 7.1.0-rc2-00726-g8ab0a3092b56-dirty #2 PREEMPT [ 598.542733] Hardware name: Radxa ROCK 5T (DT) [ 598.543746] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 598.544991] pc : dma_unmap_sg_attrs (kernel/dma/mapping.c:0) [ 598.546021] lr : panthor_gem_free_object (include/linux/dma-mapping.h:565 drivers/gpu/drm/panthor/panthor_gem.c:308 drivers/gpu/drm/panthor/panthor_gem.c:469) panthor [ 598.547180] sp : ffff80008835bb90 [ 598.548123] x29: ffff80008835bb90 x28: ffff00012610bf00 x27: 0000000000000000 [ 598.549412] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 598.550696] x23: ffff000127194600 x22: ffff0001271943d0 x21: ffff000118671000 [ 598.551984] x20: ffff000127194200 x19: ffff000127194600 x18: 00000000002ab980 [ 598.553273] x17: 00000000002ab980 x16: ffffa39a6b372a04 x15: 0000000000000000 [ 598.554568] x14: 0000000000000010 x13: 0000000000000000 x12: 000000000000003c [ 598.555864] x11: 0000000000000002 x10: ffff000100a5d000 x9 : ffff000118671000 [ 598.557164] x8 : ffff000102f8b490 x7 : ffff000149569000 x6 : ffff000149569000 [ 598.558461] x5 : ffff000100faa7e8 x4 : 0000000000000000 x3 : 0000000000000000 [ 598.559763] x2 : 0000000000000010 x1 : ffff000127194000 x0 : 000000000040000f [ 598.561069] Call trace: [ 598.561961] dma_unmap_sg_attrs (kernel/dma/mapping.c:0) (P) [ 598.563038] panthor_gem_free_object (include/linux/dma-mapping.h:565 drivers/gpu/drm/panthor/panthor_gem.c:308 drivers/gpu/drm/panthor/panthor_gem.c:469) panthor [ 598.564218] drm_gem_object_free (drivers/gpu/drm/drm_gem.c:1148) drm [ 598.565386] panthor_kernel_bo_destroy (include/linux/kref.h:65 include/drm/drm_gem.h:565 include/drm/drm_gem.h:578 drivers/gpu/drm/panthor/panthor_gem.c:1317) panthor [ 598.566575] panthor_fw_unplug (drivers/gpu/drm/panthor/panthor_fw.c:1306) panthor [ 598.567705] panthor_device_unplug (drivers/gpu/drm/panthor/panthor_device.c:103) panthor [ 598.568878] panthor_remove (drivers/gpu/drm/panthor/panthor_drv.c:1846) panthor [ 598.569991] platform_remove (drivers/base/platform.c:1435) [ 598.571029] device_release_driver_internal (drivers/base/dd.c:619 drivers/base/dd.c:1352 drivers/base/dd.c:1375) [ 598.572209] driver_detach (drivers/base/dd.c:1438) [ 598.573237] bus_remove_driver (drivers/base/bus.c:825) [ 598.574304] driver_unregister (drivers/base/driver.c:277) [ 598.575363] platform_driver_unregister (drivers/base/platform.c:920) [ 598.576494] cleanup_module (drivers/gpu/drm/panthor/panthor_devfreq.c:134) panthor [ 598.577617] __arm64_sys_delete_module (kernel/module/main.c:863 kernel/module/main.c:804 kernel/module/main.c:804) [ 598.578751] invoke_syscall (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49) [ 598.579794] el0_svc_common (arch/arm64/kernel/syscall.c:121) [ 598.580842] do_el0_svc (arch/arm64/kernel/syscall.c:140) [ 598.581862] el0_svc (arch/arm64/kernel/entry-common.c:723) [ 598.582853] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:742) [ 598.583949] el0t_64_sync (arch/arm64/kernel/entry.S:594) Kind regards, Nicolas Frattaroli

4 days, 17 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig