On Mon Sep 28, 2026 at 10:32 AM CEST, Philipp Stanner wrote:
> On Mon, 2026-09-28 at 10:11 +0200, Danilo Krummrich wrote:
>> On Mon Sep 28, 2026 at 9:52 AM CEST, Philipp Stanner wrote:
>> > > > So I suppose we agree that a warning is fine. It won't fire in JQ
>> > > > anyways, but might benefit others.
>> > >
>> > > What scenario are you thinking of?
>> >
>> > Drivers doing "rather questionable" things, like we've seen a great
>> > many times already ;)
>> >
>> > Note that the dma_fence backend fires a WARN_ON if a fence is freed
>> > unsignaled, too, for the same reason.
>> >
>> > Life finds a way.
>>
>> I'd rather you engage with the arguments I made above and give a concrete
>> example of how it "might benefit others", instead of resorting to know-it-all
>> platitudes.
>
> Stating that I cannot know nor conceive all possible patterns and
> misbehaviors is quite literally me acknowledging that I do *not* "know
> it all".
I mean, you expressed a concern about a fence being signaled before the hardware
has been torn down accordingly. I provided arguments why I don't see that the
concern holds and then you mentioned that the warning "might benefit others".
To me this sounded as if you had concrete scenarios in mind, which doesn't seem
to be the case. If that's correct, and given that there was no reply to my
arguments, it seems we can just remove it.
Maybe to further explain my reasoning:
The concern was that it could happen that the DriverFence is dropped while the
hardware still utilizes the memory "protected" by the fence. As mentioned, to me
this is not a concern because of the programming model we have in Rust. Take
this analogous DMA memory example:
struct Channel<'a> {
shared: dma::Coherent<'a, Data>,
}
impl Drop for Channel<'_> {
fn drop(&mut self) {
self.stop_hardware();
shared.free();
}
}
We could use the exact same argument to require people to explicitly call free()
on a dma::Coherent allocation as the underlying hardware (represented by the
channel) could still use the dma::Coherent allocation if we "drop it
accidentally".
But as you can see, the ownership is already properly expressed by Rust, the
Channel owns the dma::Coherent allocation, so the memory can just be freed in
Coherent::drop().
The same applies to DriverFence, the thing that takes ownership is the thing
that operates the hardware.
> With this patch I was just trying to accommodate your post-merge
> request for replacing pr_ with dev_err() or WARN_ON. If you think
> neither is actually necessary, that's also fine by me.
I did arrive at the conclusion to discuss whether we can't just get rid of the
warning entirely in my first reply [1], which you refer to, already.
[1] https://lore.kernel.org/all/[email protected]/
