mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Demi Marie Obenour <demiobenour@gmail.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	"Huang, Honglei1" <Honglei1.Huang@amd.com>,
	David Airlie <airlied@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Gurchetan Singh <gurchetansingh@chromium.org>,
	Chia-I Wu <olvaffe@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Simona Vetter <simona@ffwll.ch>, Rob Clark <robdclark@gmail.com>,
	Huang Rui <ray.huang@amd.com>
Cc: dri-devel@lists.freedesktop.org, virtualization@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 7/7] drm/virtio: implement userptr: add interval tree
Date: Wed, 2 Apr 2025 14:45:35 -0400	[thread overview]
Message-ID: <6fb21077-c254-49a7-97fd-64c87322ea43@gmail.com> (raw)
In-Reply-To: <975582a3-313b-4989-aac2-c3b309ba55b6@collabora.com>

On 4/2/25 8:34 AM, Dmitry Osipenko wrote:
> On 4/2/25 04:53, Huang, Honglei1 wrote:
>>
>> On 2025/3/30 19:57, Dmitry Osipenko wrote:
>>> If the purpose of this feature is to dedup usrptr BOs of a the single
>>> process/application, can this can be done in userspace? 
> 
> I assume it can be done in userspace, don't see why it needs to be in
> kernel.

The kernel definitely does not need to be responsible for deduplication,
but is it safe to allow userspace to create overlapping BOs, especially
ones that are partially but not entirely overlapping?  If the userspace
libraries ~everyone will be using refuse to create such BOs, then
overlapping BOs will be tested by ~nobody, and untested kernel code is
a good place for security vulnerabilities to linger.

If there are no legitimate use-cases for overlapping BOs, I would treat
attempts to create them as an errors and return -EINVAL, indicating that
the userspace code attempting to create them is buggy.  Userspace can
deduplicate the BOs itself if necessary.  Of course, there need to be
tests for userspace attempting to create overlapping BOs, including
attempting to do so concurrently from multiple threads.

That said, probably the most important part is consistency with userptr
in other (non-virtio) drivers, such as Intel and AMD.  If they allow
overlapping userptr BOs, then virtio should too; if they do not, then
virtio should also forbid them.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

  reply	other threads:[~2025-04-02 18:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-21  8:00 [PATCH v2 0/7] *** Add virtio gpu userptr support *** Honglei Huang
2025-03-21  8:00 ` [PATCH v2 1/7] virtio-gpu api: add HSAKMT context Honglei Huang
2025-03-21  8:00 ` [PATCH v2 2/7] virtio-gpu api: add blob userptr resource Honglei Huang
2025-03-21  8:00 ` [PATCH v2 3/7] drm/virtgpu " Honglei Huang
2025-03-21  8:00 ` [PATCH v2 4/7] drm/virtio: implement userptr: probe for the feature Honglei Huang
2025-03-21  8:00 ` [PATCH v2 5/7] drm/virtio: implement userptr: add userptr obj Honglei Huang
2025-03-21  8:00 ` [PATCH v2 6/7] drm/virtio: advertise base userptr feature to userspace Honglei Huang
2025-03-21  8:00 ` [PATCH v2 7/7] drm/virtio: implement userptr: add interval tree Honglei Huang
2025-03-30 11:57   ` Dmitry Osipenko
2025-03-30 12:04     ` Dmitry Osipenko
2025-04-02  1:53     ` Huang, Honglei1
2025-04-02 12:34       ` Dmitry Osipenko
2025-04-02 18:45         ` Demi Marie Obenour [this message]
2025-04-03  3:28           ` Huang, Honglei1
2025-04-03 16:44             ` Dmitry Osipenko
2025-03-29 19:56 ` [PATCH v2 0/7] *** Add virtio gpu userptr support *** Demi Marie Obenour
2025-04-02  1:47   ` [PATCH v2 0/7] Add virtio gpu userptr support Huang, Honglei1

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=6fb21077-c254-49a7-97fd-64c87322ea43@gmail.com \
    --to=demiobenour@gmail.com \
    --cc=Honglei1.Huang@amd.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=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=olvaffe@gmail.com \
    --cc=ray.huang@amd.com \
    --cc=robdclark@gmail.com \
    --cc=simona@ffwll.ch \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®