From: Daniel Vetter <daniel@ffwll.ch>
To: Daniel Stone <daniel@fooishbar.org>
Cc: "Hans de Goede" <hdegoede@redhat.com>,
"Maxime Ripard" <mripard@redhat.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Brian Starkey" <Brian.Starkey@arm.com>,
"John Stultz" <jstultz@google.com>,
"T.J. Mercier" <tjmercier@google.com>,
"Christian König" <christian.koenig@amd.com>,
"Lennart Poettering" <mzxreary@0pointer.de>,
"Robert Mader" <robert.mader@collabora.com>,
"Sebastien Bacher" <sebastien.bacher@canonical.com>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
linaro-mm-sig@lists.linaro.org,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Bryan O'Donoghue" <bryan.odonoghue@linaro.org>,
"Milan Zamazal" <mzamazal@redhat.com>,
"Andrey Konovalov" <andrey.konovalov.ynk@gmail.com>
Subject: Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?
Date: Thu, 16 May 2024 12:18:12 +0200 [thread overview]
Message-ID: <ZkXdZBwPvZun33Fi@phenom.ffwll.local> (raw)
In-Reply-To: <CAPj87rPywSjKLrv00N-0SrkDndPdYGCBeveO0adh4xGCp20h9g@mail.gmail.com>
On Thu, May 09, 2024 at 10:23:16AM +0100, Daniel Stone wrote:
> Hi,
>
> On Wed, 8 May 2024 at 16:49, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote:
> > > Right now, if your platform requires CMA for display, then the app
> > > needs access to the GPU render node and the display node too, in order
> > > to allocate buffers which the compositor can scan out directly. If it
> > > only has access to the render nodes and not the display node, it won't
> > > be able to allocate correctly, so its content will need a composition
> > > pass, i.e. performance penalty for sandboxing. But if it can allocate
> > > correctly, then hey, it can exhaust CMA just like heaps can.
> > >
> > > Personally I think we'd be better off just allowing access and
> > > figuring out cgroups later. It's not like the OOM story is great
> > > generally, and hey, you can get there with just render nodes ...
> >
> > Imo the right fix is to ask the compositor to allocate the buffers in this
> > case, and then maybe have some kind of revoke/purge behaviour on these
> > buffers. Compositor has an actual idea of who's a candidate for direct
> > scanout after all, not the app. Or well at least force migrate the memory
> > from cma to shmem.
> >
> > If you only whack cgroups on this issue you're still stuck in the world
> > where either all apps together can ddos the display or no one can
> > realistically direct scanout.
>
> Mmm, back to DRI2. I can't say I'm wildly enthused about that, not
> least because a client using GPU/codec/etc for those buffers would
> have to communicate its requirements (alignment etc) forward to the
> compositor in order for the compositor to allocate for it. Obviously
> passing the constraints etc around isn't a solved problem yet, but it
> is at least contained down in clients rather than making it back and
> forth between client and compositor.
I don't think you need the compositor to allocate the buffer from the
requirements, you only need a protocol that a) allocates a buffer of a
given size from a given heap and b) has some kinda of revoke provisions so
that the compositor can claw back the memory again when it needs it.
> I'm extremely not-wild about the compositor migrating memory from CMA
> to shmem behind the client's back, and tbh I'm not sure how that would
> even work if the client has it pinned through whatever API it's
> imported into.
Other option is revoke on cma buffers that are allocated by clients, for
the case the compositor needs it.
> Anyway, like Laurent says, if we're deciding that heaps can't be used
> by generic apps (unlike DRM/V4L2/etc), then we need gralloc.
gralloc doesn't really fix this, it's just abstraction around how/where
you allocate?
Anyway the current plan is that we all pretend this issue of CMA allocated
buffers don't exist and we let clients allocate without limits. Given that
we don't even have cgroups to sort out the mess for anything else I
wouldn't worry too much ...
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2024-05-16 10:18 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 11:49 Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ? Hans de Goede
2024-05-06 12:05 ` Maxime Ripard
2024-05-06 12:11 ` Hans de Goede
2024-05-06 13:38 ` Daniel Vetter
2024-05-06 14:01 ` Hans de Goede
2024-05-07 11:15 ` Daniel Vetter
2024-05-08 5:46 ` Daniel Stone
2024-05-08 8:33 ` Daniel Vetter
2024-05-08 8:38 ` Daniel Stone
2024-05-08 15:49 ` Daniel Vetter
2024-05-09 9:23 ` Daniel Stone
2024-05-16 10:18 ` Daniel Vetter [this message]
2024-05-13 13:51 ` Simon Ser
2024-05-16 10:13 ` Daniel Vetter
2024-05-07 13:34 ` Dmitry Baryshkov
2024-05-07 18:59 ` Laurent Pinchart
2024-05-22 13:34 ` Maxime Ripard
2024-05-23 9:41 ` Daniel Vetter
2024-05-07 13:32 ` Dmitry Baryshkov
2024-05-07 14:34 ` Hans de Goede
2024-05-07 15:09 ` Dmitry Baryshkov
2024-05-07 15:15 ` Bryan O'Donoghue
2024-05-07 15:19 ` Dmitry Baryshkov
2024-05-07 18:40 ` Laurent Pinchart
2024-05-07 19:59 ` Dmitry Baryshkov
2024-05-07 20:15 ` Laurent Pinchart
2024-05-08 8:39 ` Daniel Vetter
2024-05-08 21:54 ` Laurent Pinchart
2024-05-13 8:39 ` Maxime Ripard
2024-05-07 17:36 ` Daniel Vetter
2024-05-07 18:36 ` Laurent Pinchart
2024-05-07 20:07 ` Nicolas Dufresne
2024-05-08 8:36 ` Daniel Vetter
2024-05-08 21:51 ` Laurent Pinchart
2024-05-08 21:52 ` Laurent Pinchart
2024-05-13 8:29 ` Maxime Ripard
2024-05-13 8:34 ` Laurent Pinchart
2024-05-13 15:10 ` Nicolas Dufresne
2024-05-14 20:42 ` Laurent Pinchart
2024-05-15 17:43 ` nicolas.dufresne
2024-05-16 11:27 ` Laurent Pinchart
2024-05-16 17:11 ` nicolas.dufresne
2024-05-21 8:43 ` Maxime Ripard
2024-05-21 14:18 ` nicolas.dufresne
2024-05-16 7:00 ` Simon Ser
2024-05-16 11:20 ` Laurent Pinchart
2024-05-22 13:02 ` Nicolas Dufresne
2024-05-13 13:42 ` Nicolas Dufresne
2024-05-13 13:51 ` Maxime Ripard
2024-05-13 15:06 ` Nicolas Dufresne
2024-05-14 20:45 ` Laurent Pinchart
2024-05-14 20:52 ` Nicolas Dufresne
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=ZkXdZBwPvZun33Fi@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=Brian.Starkey@arm.com \
--cc=andrey.konovalov.ynk@gmail.com \
--cc=benjamin.gaignard@collabora.com \
--cc=bryan.odonoghue@linaro.org \
--cc=christian.koenig@amd.com \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=jstultz@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mripard@redhat.com \
--cc=mzamazal@redhat.com \
--cc=mzxreary@0pointer.de \
--cc=robert.mader@collabora.com \
--cc=sebastien.bacher@canonical.com \
--cc=sumit.semwal@linaro.org \
--cc=tjmercier@google.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).