On Mon, Jun 28, 2021 at 12:18 PM Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > > > > On 14/05/2021 16:10, Christian König wrote: > > Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin: > >> > >> On 14/05/2021 15:56, Christian König wrote: > >>> Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin: > >>>> > >>>> On 14/05/2021 14:53, Christian König wrote: > >>>>>> > >>>>>> David also said that you considered sysfs but were wary of > >>>>>> exposing process info in there. To clarify, my patch is not > >>>>>> exposing sysfs entry per process, but one per open drm fd. > >>>>>> > >>>>> > >>>>> Yes, we discussed this as well, but then rejected the approach. > >>>>> > >>>>> To have useful information related to the open drm fd you need to > >>>>> related that to process(es) which have that file descriptor open. > >>>>> Just tracking who opened it first like DRM does is pretty useless > >>>>> on modern systems. > >>>> > >>>> We do update the pid/name for fds passed over unix sockets. > >>> > >>> Well I just double checked and that is not correct. > >>> > >>> Could be that i915 has some special code for that, but on my laptop I > >>> only see the X server under the "clients" debugfs file. > >> > >> Yes we have special code in i915 for this. Part of this series we are > >> discussing here. > > > > Ah, yeah you should mention that. Could we please separate that into > > common code instead? Cause I really see that as a bug in the current > > handling independent of the discussion here. > > What we do in i915 is update the pid and name when a task different to > the one which opened the fd does a GEM context create ioctl. > > Moving that to DRM core would be along the lines of doing the same check > and update on every ioctl. Maybe allow the update to be one time only if > that would work. Would this be desirable and acceptable? If so I can > definitely sketch it out. If we go with fdinfo for these it becomes clear who all owns the file, since it's then a per-process thing. Not sure how much smarts we should have for internal debugfs output. Maybe one-shot update on first driver ioctl (since if you're on render nodes then X does the drm auth dance, so "first ioctl" is wrong). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
