Re: [PATCH] dma-fence: Correct return of dma_fence_driver_name()

[Tvrtko Ursulin <tvrtko.ursulin@igalia.com>]

On 24/10/2025 14:13, Danilo Krummrich wrote:
> On 10/24/25 2:40 PM, Tvrtko Ursulin wrote:
>> You trim too much of the quote making it unclear if you read the whole story.
> 
> I'm well aware of the context.

Good to know. I am coming from the angle that netiquette, at least in 
the olden days, used to be that when you join an established thread you 
don't trim too much of the context. For the benefit of people joining 
the thread at that very point, especially when re-raising an argument 
which has already been discussed.

>> If the driver isn't detached from the signalled fence then it is vulnerable to
>> use after free.
> When someone just reads "detached-driver" is creates the impression that the
> driver is unbound from its device, since this is what this term is usually used for.
> 
> (And this is even the case you want to protect against, i.e. the string behind
> the pointer returned by get_driver_name() has been freed.)

One of the cases just to be clear. The driver getting unbound from the 
device is not *the* case.

In fact with xe the bug was exploitable by just closing the render node 
fd and then querying the fence. Hence detached in this context is more 
than unbound or unloaded.
> However, the condition that has changed when you print "driver-detached" is that
> the fence has been signaled, independent of whether the driver has been detached
> from the device.
> 
> Now, you can argue that you mean "driver has been detached from the fence",
> which means something along the lines of "the driver has no business with the
> fence anymore", but this is not what people think of when they read
> "detached-driver".Okay people. :)

How about "unknown-driver", would that satisfy you?

Regards,

Tvrtko