From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Jocelyn Falempe <jfalempe@redhat.com>,
Ryosuke Yasuoka <ryasuoka@redhat.com>,
airlied@redhat.com, kraxel@redhat.com,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, daniel@ffwll.ch,
christophe.jaillet@wanadoo.fr
Cc: virtualization@lists.linux.dev,
spice-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5] drm/virtio: Add drm_panic support
Date: Mon, 3 Feb 2025 04:07:13 +0300 [thread overview]
Message-ID: <b3fe0f90-761b-4dea-aa43-e7187a2ffd5a@collabora.com> (raw)
In-Reply-To: <a0fc9b8c-e86d-46a2-a1d2-5ce8793ad2a5@redhat.com>
On 12/2/24 20:19, Jocelyn Falempe wrote:
>>>
>>> I've now noticed that drm_gem_shmem_vmap() expects BO reservation lock
>>> to be held and we can't take lock it at a panic time.
>>>
>>> https://elixir.bootlin.com/linux/v6.12.1/source/drivers/gpu/drm/
>>> drm_gem_shmem_helper.c#L330
>>>
>>> This resv warning isn't triggered because bo->base.vaddr is set for VT
>>> framebufffer BO when panic happens.
>
> I usually test using gnome desktop in the VM, and in this case vaddr is
> not set, and calling vmap() is needed. (and I don't get the warning, I
> will check why).
All those get_pages() and vmap() that drm_gem_shmem_vmap() uses may
sleep. You'll need to add atomic variants for the vmap funcs if it's
really needed.
Like I said in the comment to v6, let's start with rejecting BOs that
aren't vmapped. If atomic vmap will become needed, it will be a separate
problem to solve.
--
Best regards,
Dmitry
next prev parent reply other threads:[~2025-02-03 1:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-29 12:24 [PATCH v5] drm/virtio: Add drm_panic support Ryosuke Yasuoka
2024-12-02 14:29 ` Dmitry Osipenko
2024-12-02 16:19 ` Dmitry Osipenko
2024-12-02 17:19 ` Jocelyn Falempe
2025-02-03 1:07 ` Dmitry Osipenko [this message]
2024-12-10 12:24 ` Ryosuke Yasuoka
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=b3fe0f90-761b-4dea-aa43-e7187a2ffd5a@collabora.com \
--to=dmitry.osipenko@collabora.com \
--cc=airlied@redhat.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jfalempe@redhat.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=ryasuoka@redhat.com \
--cc=spice-devel@lists.freedesktop.org \
--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.