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
