From: Emil Velikov <emil.velikov@collabora.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: keithp@keithp.com, airlied@linux.ie,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
andresx7@gmail.com, Alexander.Deucher@amd.com
Subject: Re: [PATCH 1/2] drm/i915: remove DRM_AUTH from IOCTLs which also have DRM_RENDER_ALLOW
Date: Wed, 17 Apr 2019 19:18:30 +0100 [thread overview]
Message-ID: <20190417181830.GC1094@arch-x1c3> (raw)
In-Reply-To: <20190417160639.GB1094@arch-x1c3>
On 2019/04/17, Emil Velikov wrote:
> On 2019/04/17, Christian König wrote:
> > This is to work around problems with libva and vainfo.
> >
> This part reverts a commit from 2013. Something I would wager that will cause
> multiple problems across the board.
>
> If we look at the intel libva driver in particular, as-is this will cause all
> get param queries on the render node to fail. Something that used to work
> since render node support was introduced.
>
> Analogously this will break the Intel Mesa driver when using the render node
> and issuing the ioctls.
>
Silly moment of mine - I've misread which piece gets reverted.
Pardon for the noise.
Personally I would use something like the following, which helps the reader
understand what's happening.
At the moment the following ioctls are exposed by both primary and render
nodes. Yet there's no code-flow difference based on the originating node type.
Thus in reality the exact same code is executed without the "authentication".
So let's drop the DRM_AUTH annotation.
In practise this fixes cases like (but not limited to) libva where the primary
node is opened, yet authentication is lacking prior to issuing the ioctl.
I915_GETPARAM
I915_GEM_EXECBUFFER2_WR
I915_GEM_BUSY
I915_GEM_THROTTLE
I915_GEM_WAIT
HTH
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-04-17 18:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 11:25 [PATCH 1/2] drm/i915: remove DRM_AUTH from IOCTLs which also have DRM_RENDER_ALLOW Christian König
2019-04-17 11:25 ` [PATCH 2/2] drm: revert "allow render capable master with DRM_AUTH ioctls" Christian König
2019-04-17 11:39 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: remove DRM_AUTH from IOCTLs which also have DRM_RENDER_ALLOW Patchwork
2019-04-17 11:42 ` [PATCH 1/2] " Chris Wilson
2019-04-17 12:08 ` ✓ Fi.CI.BAT: success for series starting with [1/2] " Patchwork
2019-04-17 12:51 ` [PATCH 1/2] " Daniel Vetter
2019-04-17 16:06 ` Emil Velikov
2019-04-17 18:18 ` Emil Velikov [this message]
2019-04-17 20:27 ` ✗ Fi.CI.IGT: failure for series starting with [1/2] " Patchwork
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=20190417181830.GC1094@arch-x1c3 \
--to=emil.velikov@collabora.com \
--cc=Alexander.Deucher@amd.com \
--cc=airlied@linux.ie \
--cc=andresx7@gmail.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=keithp@keithp.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