virtio_gpu_cursor_plane_update() calls virtio_gpu_array_lock_resv()
but ignores its return value. The function can fail in two ways:
- dma_resv_lock_interruptible() returns -ERESTARTSYS when a signal
is delivered while waiting for the reservation lock.
- dma_resv_reserve_fences() returns -ENOMEM if it fails to allocate
a fence slot; in this case lock_resv unlocks before returning.
In both cases the resv lock is not held on return. The cursor path
proceeds to queue a fenced transfer command. The queue path then
walks the object array and calls dma_resv_add_fence() on the cursor
BO's reservation. dma_resv_add_fence() requires the resv lock to be
held; with lockdep enabled the missing lock trips
dma_resv_assert_held():
WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840
Call Trace:
virtio_gpu_array_add_fence+0xcd/0x140
virtio_gpu_queue_ctrl_sgs
virtio_gpu_queue_fenced_ctrl_buffer+0x578/0xfb0
virtio_gpu_cursor_plane_update+0x411/0xbc0
drm_atomic_helper_commit_planes+0x497/0xf10
...
drm_mode_cursor_ioctl+0xd4/0x110
drm_ioctl+0x5e6/0xc60
__x64_sys_ioctl+0x18e/0x210
Beyond the WARN, mutating the dma_resv fence list without the lock
races with concurrent readers/writers and can corrupt the list.
Check the return value of virtio_gpu_array_lock_resv(). On failure,
drop the references taken by virtio_gpu_array_add_obj() with
virtio_gpu_array_put_free() (which does not unlock, matching the
not-locked state) and return without queueing the command. A
skipped cursor frame is harmless; the WARN and the underlying race
are not.
The bug was reported by syzbot, triggered via fault injection
(fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the
-ENOMEM branch in dma_resv_reserve_fences().
Reported-by: syzbot+72bd3dd3a5d5f39a0271(a)syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=72bd3dd3a5d5f39a0271
Fixes: 5cfd31c5b3a3 ("drm/virtio: fix virtio_gpu_cursor_plane_update().")
Cc: stable(a)vger.kernel.org
Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com>
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c
index a126d1b25f46..ca379b08b9ec 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -459,7 +459,10 @@ static void virtio_gpu_cursor_plane_update(struct drm_plane *plane,
if (!objs)
return;
virtio_gpu_array_add_obj(objs, vgfb->base.obj[0]);
- virtio_gpu_array_lock_resv(objs);
+ if (virtio_gpu_array_lock_resv(objs)) {
+ virtio_gpu_array_put_free(objs);
+ return;
+ }
virtio_gpu_cmd_transfer_to_host_2d
(vgdev, 0,
plane->state->crtc_w,
--
2.43.0
On Sat, May 09, 2026 at 01:31:56PM +0800, Xu Yilun wrote:
> > Would you be open to an in-between? The exporter and importer both
> > have information that should not leak into each other's drivers.
> >
> > What if the dmabuf mapping type core code was the only thing that had
> > access to *BOTH*? The exporter provides the address data, the importer
> > provides the iommu_domain. The core code, and only the core code, has
> > both and does the required operation?
>
> I think that may not work for KVM. On IOMMU side, IOMMUFD acts as the
> address space (iova) manager and dma_api/IOMMU driver acts as the
> actual page table mapper. But for KVM, it is both. KVM doesn't allow
> another component to provide an unknown address space (GPA space) and
> say "map it", so doesn't expose to other components about "KVM domain".
>
> Even if we expose "KVM domain", KVM still acts as the importer and the
> mapper, is it wierd to say we trust KVM-the-mapper, but don't trust
> KVM-the-as-manager?
>
> Is it also wierd that we trust IOMMU-the-mapper, but don't trust
> IOMMUFD-the-as-manager? There are more IOMMU drivers than IOMMUFD...
Yeah, it doesn't work well for kvm, and yes it is really weird and
worse that phys in every way..
Jason
On Thu, May 07, 2026 at 05:16:56PM +1000, Alexey Kardashevskiy wrote:
> true but either way dmabuf slicing will be directed by QEMU's
> msix-table emulation MR and this slicing needs to match the TDISP
> report so I'll have to teach QEMU these reports, right? I am worried
> if I miss something obvious, again. Thanks,
I don't think so.. It just needs to slice it into the MSI page
blindly. When the VM goes to validate the TDISP report against the
mappings it will fail to accept the device if there is a mismatch.
The only thing qemu could do is fail sooner, but I don't know that is
worth the complexity as we do expect all devices to have their MSI
range unprotected.
Jason
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/
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
Hi,
This is a patch series covering the support for protected mode execution in
Mali Panthor CSF kernel driver.
It builds on the initial RFC posted by Florent Tomasin back in January of 2025.
The initial RFC can be found here:
https://lore.kernel.org/lkml/cover.1738228114.git.florent.tomasin@arm.com/
The Mali CSF GPUs come with the support for protected mode execution at the
HW level. This feature requires two main changes in the kernel driver:
1) Configure the GPU with a protected buffer. The system must provide a DMA
heap from which the driver can allocate a protected buffer.
It can be a carved-out memory or dynamically allocated protected memory region.
Some system includes a trusted FW which is in charge of the protected memory.
Since this problem is integration specific, the Mali Panthor CSF kernel
driver must import the protected memory from a device specific exporter.
2) Handle enter and exit of the GPU HW from normal to protected mode of execution.
FW sends a request for protected mode entry to the kernel driver.
The acknowledgment of that request is a scheduling decision. Effectively,
protected mode execution should not overrule normal mode of execution.
A fair distribution of execution time will guaranty the overall performance
of the device, including the UI (usually executing in normal mode),
will not regress when a protected mode job is submitted by an application.
Background
----------
Current Mali Panthor CSF driver does not allow a user space application to
execute protected jobs on the GPU. This use case is quite common on end-user-device.
A user may want to watch a video or render content that is under a "Digital Right
Management" protection, or launch an application with user private data.
1) User-space:
In order for an application to execute protected jobs on a Mali CSF GPU the
user space application must submit jobs to the GPU within a "protected regions"
(range of commands to execute in protected mode).
Find here an example of a command buffer that contains protected commands:
```
<--- Normal mode ---><--- Protected mode ---><--- Normal mode --->
+-------------------------------------------------------------------------+
| ... | CMD_0 | ... | CMD_N | PROT_REGION | CMD_N+1 | ... | CMD_N+M | ... |
+-------------------------------------------------------------------------+
```
The PROT_REGION command acts as a barrier to notify the HW of upcoming
protected jobs. It also defines the number of commands to execute in protected
mode.
The Mesa definition of the opcode can be found here:
https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/panfrost/lib/genxm…
2) Kernel-space:
When loading the FW image, the Kernel driver must also load the data section of
CSF FW that comes from the protected memory, in order to allow FW to execute in
protected mode.
Important: this memory is not owned by any process. It is a GPU device level
protected memory.
In addition, when a CSG (group) is created, it must have a protected suspend buffer.
This memory is allocated within the kernel but bound to a specific CSG that belongs
to a process. The kernel owns this allocation and does not allow user space mapping.
The format of the data in this buffer is only known by the FW and does not need to
be shared with other entities. The purpose of this buffer is the same as the normal
suspend buffer but for protected mode. FW will use it to suspend the execution of
PROT_REGION before returning to normal mode of execution.
Design decisions
----------------
The Mali Panthor CSF kernel driver will allocate protected DMA buffers
using a global protected DMA heap. The name of the heap can vary on
the system and is integration specific. Therefore, the kernel driver
will retrieve it using the DTB entry: "protected-heap-name".
The Mali Panthor CSF kernel driver will handle enter/exit of protected
mode with a fair consideration of the job scheduling.
If the system integrator does not provide a protected DMA heap, the driver
will not allow any protected mode execution.
Patch series
------------
[PATCHES 1-2]:
Thees patches comes from the following patch series:
https://lore.kernel.org/lkml/20240720071606.27930-1-yunfei.dong@mediatek.co…
These extend the DMA-buf heap API to allow other kernel drivers to Find
and allocate memory from dma heaps.
Note: This patch series do not include a protected DMA heap, as this is
platform specific.
* dma-heap: Add proper kref handling on dma-buf heaps
* dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps
[PATCHES 3, 5 and 6]:
These are refactoring to aid the implementation of the protected rendering
feature itself.
* drm/panthor: De-duplicate FW memory section sync
* drm/panthor: Minor scheduler refactoring
* drm/panthor: Explicit expansion of locked VM region
[Patch 4]:
This introduces allocation of protected memory inside the Panthor driver.
It also ensures the protected FW sections are loaded.
* drm/panthor: Add support for protected memory allocation in panthor
[PATCH 7]:
This patch implements the logic to handle enter/exit of the GPU protected
mode in Panthor CSF driver.
Note: to prevent scheduler priority inversion, only a single CSG is allowed
to execute while in protected mode. It must be the top priority one.
* drm/panthor: Add support for entering and exiting protected mode
[PATCH 8]:
The final patch exposes this feature via the uAPI.
* drm/panthor: Expose protected rendering features
Testing
-------
1) Platform and development environment
Any platform containing a Mali CSF type of GPU and a protected memory allocator
that is based on DMA Heap can be used. For example, it can be a physical platform
or a simulator such as Arm Total Compute FVPs platforms. Reference to the latter:
https://developer.arm.com/Tools%20and%20Software/Fixed%20Virtual%20Platform…
2) Mesa:
PanVK support can be found here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40044
This is still work in progress.
Constraints
-----------
At the time of developing the feature, Linux kernel does not have a generic
way of implementing protected DMA heaps. The patch series relies on previous
work to expose the DMA heap API to the kernel drivers.
The Mali CSF GPU requires device level allocated protected memory, which do
not belong to a process. The current Linux implementation of DMA heap only
allows a user space program to allocate from such heap. Having the ability
to allocate this memory at the kernel level via the DMA heap API would allow
support for protected mode on Mali CSF GPUs.
Florent Tomasin (3):
drm/panthor: Add support for protected memory allocation in panthor
drm/panthor: Minor scheduler refactoring
drm/panthor: Add support for entering and exiting protected mode
John Stultz (2):
dma-heap: Add proper kref handling on dma-buf heaps
dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps
Ketil Johnsen (3):
drm/panthor: De-duplicate FW memory section sync
drm/panthor: Explicit expansion of locked VM region
drm/panthor: Expose protected rendering features
Documentation/gpu/panthor.rst | 47 +++
drivers/dma-buf/dma-heap.c | 109 ++++++-
drivers/gpu/drm/panthor/Kconfig | 1 +
drivers/gpu/drm/panthor/panthor_device.c | 29 +-
drivers/gpu/drm/panthor/panthor_device.h | 15 +
drivers/gpu/drm/panthor/panthor_drv.c | 21 +-
drivers/gpu/drm/panthor/panthor_fw.c | 137 ++++++--
drivers/gpu/drm/panthor/panthor_fw.h | 7 +
drivers/gpu/drm/panthor/panthor_gem.c | 77 ++++-
drivers/gpu/drm/panthor/panthor_gem.h | 16 +-
drivers/gpu/drm/panthor/panthor_gpu.c | 14 +-
drivers/gpu/drm/panthor/panthor_gpu.h | 6 +
drivers/gpu/drm/panthor/panthor_heap.c | 2 +
drivers/gpu/drm/panthor/panthor_mmu.c | 79 +++--
drivers/gpu/drm/panthor/panthor_sched.c | 387 ++++++++++++++++++-----
include/linux/dma-heap.h | 8 +
include/uapi/drm/panthor_drm.h | 45 ++-
17 files changed, 864 insertions(+), 136 deletions(-)
--
2.43.0