[PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Emil Velikov
emil.l.velikov at gmail.com
Fri Jun 21 11:58:45 UTC 2019
On 2019/06/21, Koenig, Christian wrote:
> Am 21.06.19 um 12:53 schrieb Emil Velikov:
> > On 2019/06/21, Koenig, Christian wrote:
> >> [SNIP]
> >> Well partially. That RADV broke is unfortunate, but we have done so many
> >> customized userspace stuff both based on Mesa/DDX as well as closed
> >> source components that it is just highly likely that we would break
> >> something else as well.
> >>
> > As an engineer I like to work with tangibles. The highly likely part is
> > probable, but as mentioned multiple times the series allows for a _dead_
> > trivial way to address any such problems.
>
> Well to clarify my concern is that this won't be so trivial.
>
> You implemented on workaround for one specific case and it is perfectly
> possible that for other cases we would have to completely revert the
> removal of DRM_AUTH.
>
I would encourage you to take a closer look at my patch and point out
how parcicular cases cannot be handled.
> >>> In particular, that user-space will "remove" render nodes.
> >> Yes, that is my main concern here. You basically make render nodes
> >> superfluously. That gives userspace all legitimization to also remove
> >> support for them. That is not stupid or evil or whatever, userspace
> >> would just follow the kernel design.
> >>
> > Do you have an example of userspace doing such an extremely silly thing?
> > It does seem like suspect you're a couple of steps beyond overcautious,
> > perhaps rightfully so. Maybe you've seen some closed-source user-space
> > going crazy? Or any other projects?
>
> The key point is that I don't think this is silly or strange or crazy at
> all. See the kernel defines the interface userspace can and should use.
>
> When the kernel defines that everything will work with the primary node
> it is perfectly valid for userspace to drop support for the render node.
>
> I mean why should they keep this? Just because we tell them not to do this?
>
>From your experiense, do user-space developers care about doing (or
generally do) the right thing?
In either case, as pointed already the cat is out of the bag - has been
for years, and if developers did behave as you describe them they would
have "removed" render nodes already.
> > In other words, being cautious is great, but without references of
> > misuse it's very hard for others to draw the full picture.
> >
> >>> I'm really sad that amdgpu insists on standing out, hope one day it will
> >>> converge. Yet since all other maintainers are ok with the series, I'll
> >>> start merging patches in a few hours. I'm really sad that amdgpu wants
> >>> to stand out, hope it will converge sooner rather than later.
> >>>
> >>> Christian, how would you like amdgpu handled - with a separate flag in
> >>> the driver or shall we special case amdgpu within core drm?
> >> No, I ask you to please stick around DRM_AUTH for at least amdgpu and
> >> radeon. And NOT enable any render node functionality for them on the
> >> primary node.
> >>
> > My question is how do you want this handled:
> > - DRM_PLEASE_FORCE_AUTH - added to AMDGPU/RADEON, or
> > - driver_name == amdgpu, in core DRM.
>
> I want to keep DRM_AUTH in amdgpu and radeon for at least the next 5-10
> years.
>
Believe we're all fully aware of that fact. I'm asking which _approach_
you prefer. That said, I'll send a new patch/series and we'll nitpick it
there.
Thanks
-Emil
More information about the dri-devel
mailing list