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
