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

[Nguyen Ngoc Thang]

On 27.09.2026, Dmitry Osipenko wrote:
> kmem_cache is used by GPU drivers to avoid kmalloc stalls in a
> latency-sensitive job-submission code path.

Fair, I'll drop the kzalloc()/kfree() v2 and go back to v1's approach
(one cache, created once).

> 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].

I went and checked, and the /dev/fb angle isn't actually load-bearing
here: two virtio-gpu devices at once hit the same WARN at plain boot,
no remove/rescan or held-open fd involved ("-device virtio-gpu-pci"
twice on the QEMU command line). syzbot's repro happened to go through
the hot-unplug path, but the bug is just "a second virtio-gpu device
probes while the first one's cache is still around."

I also owe a correction: my commit message said
kmem_cache_create() fails and the device doesn't probe. That's wrong.
It WARNs and still returns a cache (merged with the existing one), so
the second device probes fine either way -- I'd just never checked
that claim against the actual behavior of kmem_cache_sanity_check().
The real problem is the duplicate name itself (confuses slabtop, per
the comment next to the check), which is what syzbot and any
panic_on_warn setup flag as a crash.

> 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.

Confirmed, and agreed -- I'll send a v3 that's v1's static
module-scope cache again, with the commit message fixed and the
two-device case as the primary trigger.

Thanks,
Nguyen Ngoc Thang