[PATCH v2 4/7] drm/panfrost: Add the ability to create submit queues

[Daniel Stone]

Hi,

On Fri, 2 Jul 2021 at 11:55, Steven Price <steven.price at arm.com> wrote:
> On 02/07/2021 11:43, Boris Brezillon wrote:
> > On Fri, 2 Jul 2021 10:56:29 +0100
> > Steven Price <steven.price at arm.com> wrote:
> >> My Vulkan knowledge is limited so I'm not sure whether this is the right
> >> approach or not. In particular is it correct that an application can
> >> create a high priority queue which could affect other (normal priority)
> >> applications?
> >
> > That's what msm does (with no extra CAPS check AFAICT), and the
> > freedreno driver can already create high priority queues if
> > PIPE_CONTEXT_HIGH_PRIORITY is passed. Not saying that's okay to allow
> > userspace to tweak the priority, but if that's a problem, other drivers
> > are in trouble too ;-).
>
> Oh well I guess if others are doing the same ;) I have to admit kbase
> has always struggled with how to identify a "privileged" process - it's
> something that makes a bit of sense on Android but for other userspaces
> there really doesn't seem to be a good way of identifying what should or
> should not be allowed to create high priority queues.

Yeah, it's a platform-specific question. Some might want to say
compositor-only, some might want to let foreground apps ramp, etc.

Thankfully, Vulkan is pretty clear that it's just a hint and the
results might be anything or nothing.

> >> Also does it really make sense to allow user space to create an
> >> unlimited number of queues? It feels like an ideal way for an malicious
> >> application to waste kernel memory.
> >
> > Same here, I see no limit on the number of queues the msm driver can
> > create. I can definitely pick an arbitrary limit of 2^16 (or 2^8 if
> > 2^16 is too high) if you prefer, but I feel like there's plenty of ways
> > to force kernel allocations already, like allocating a gazillion of 4k
> > GEM buffers (cgroup can probably limit the total amount of memory
> > allocated, but you'd still have all gem-buf meta data in kernel memory).
>
> I guess the real problem is picking a sensible limit ;) My main concern
> here is that there doesn't appear to be any memory accounted against the
> process. For GEM buffers at least there is some cost to the application
> - so an unbounded allocation isn't possible, even if the bounds are
> likely to be very high.
>
> With kbase we found that syzcaller was good at finding ways of using up
> all the memory on the platform - and if it wasn't accounted to the right
> process that meant the OOM-killer knocked out the wrong process and
> produced a bug report to investigate. Perhaps I'm just scarred by that
> history ;)

Yep, cgroup accounting and restriction is still very much unsolved.
GEM buffers let you make an outsize impact on the whole system at
little to no cost to yourself. You can also create a million syncobjs
if you want. Oh well.

Cheers,
Daniel