Re: [PATCH] drm/virtio: share one vbuf cache across all devices

From: Dmitry Osipenko

Date: Fri Oct 09 2026 - 13:40:22 EST


27.09.2026 07:09, Nguyen Ngoc Thang пишет:
> On Sun, 27 Sep 2026, Hillf Danton wrote:
>> What is unclear -- why is kmalloc failing to work in 2026?
>
> kmalloc isn't failing. The failure is in kmem_cache_create(): the driver
> creates a dedicated cache with a fixed global name for each device, so a
> second probe while the first drm_device is still alive (release is
> deferred by an open /dev/fbN) trips the duplicate-name check.
>
> Your question made me look at whether the dedicated cache is needed at all.
> A vbuf is sizeof(struct virtio_gpu_vbuffer) + 96 + 24 = 216 bytes, which
> lands in kmalloc-256 anyway, so the cache buys nothing over kzalloc()/kfree().
> Dropping it also removes the lifetime problem entirely and needs no
> module-level state.
>
> I'll send a v2 that switches the kmem_cache_zalloc() calls and
> kmem_cache_free() to kzalloc()/kfree() and deletes the cache setup and
> teardown.
>
> Thanks,
> Nguyen Ngoc Thang

kmem_cache is used by GPU drivers to avoid kmalloc stalls in a
latency-sensitive job-submission code path.

The /dev/fb reference doesn't sound right as normally removal of
framebuffers is required before GPU driver can be unbound. Such bug
reports should be treated as invalid, BTW [1].

Assume the similar "duplicated" kmemcache problem should exists if there
is more than one virtio-gpu device in a system. I suggest you to
validate this case and if it has the problem, might be better to make
kmemcache's static instead of creating dynamically.

[1] https://www.phoronix.com/news/Linux-Taint-Forced-Bind

--
Best regards,
Dmitry