From: Hillf Danton <hdanton@sina.com>
To: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Cc: David Airlie <airlied@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Dmitry Osipenko <dmitry.osipenko@collabora.com>,
Gurchetan Singh <gurchetansingh@chromium.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
dri-devel@lists.freedesktop.org, virtualization@lists.linux.dev,
linux-kernel@vger.kernel.org,
syzbot+1b129b44597a126d2d79@syzkaller.appspotmail.com
Subject: Re: [PATCH] drm/virtio: share one vbuf cache across all devices
Date: Sun, 27 Sep 2026 08:03:21 +0800 [thread overview]
Message-ID: <20260927000323.299-1-hdanton@sina.com> (raw)
In-Reply-To: <20260926162452.136863-1-ngocthang2710.1999@gmail.com>
On Sat, 26 Sep 2026 23:24:52 +0700 Nguyen Ngoc Thang wrote:
> virtio_gpu_alloc_vbufs() creates a kmem_cache with the fixed name
> "virtio-gpu-vbufs" for every device and destroys it from
> virtio_gpu_release(), which only runs once the last drm_device
> reference is dropped. If a reference outlives the PCI removal (for
> instance an open /dev/fbN), a rescan probes the device again while the
> old cache still exists:
>
> kmem_cache of name 'virtio-gpu-vbufs' already exists
> WARNING: mm/slab_common.c:111 at __kmem_cache_create_args
> Call Trace:
> virtio_gpu_alloc_vbufs
> virtio_gpu_init
> virtio_gpu_probe
> ...
> pci_rescan_bus
> rescan_store
>
> kmem_cache_create() then fails and the new device does not probe.
>
> The vbuf size is the same for every device, so create the cache once
> at module init and destroy it at module exit instead of per device.
>
What is unclear -- why is kmalloc failing to work in 2026?
next prev parent reply other threads:[~2026-09-27 0:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-26 16:24 [PATCH] drm/virtio: share one vbuf cache across all devices Nguyen Ngoc Thang
2026-09-26 16:33 ` sashiko-bot
2026-09-27 0:03 ` Hillf Danton [this message]
2026-09-27 4:09 ` Nguyen Ngoc Thang
2026-10-09 17:39 ` Dmitry Osipenko
2026-10-14 1:41 ` Hillf Danton
-- strict thread matches above, loose matches on Subject: below --
2026-10-10 15:04 Nguyen Ngoc Thang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260927000323.299-1-hdanton@sina.com \
--to=hdanton@sina.com \
--cc=airlied@redhat.com \
--cc=dmitry.osipenko@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gurchetansingh@chromium.org \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ngocthang2710.1999@gmail.com \
--cc=syzbot+1b129b44597a126d2d79@syzkaller.appspotmail.com \
--cc=tzimmermann@suse.de \
--cc=virtualization@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.