Re: [PATCH] dma-buf: Release input fences in the unwrap merge order test

[Christian König]

On 11/3/26 08:27, Krzysztof Kozlowski wrote:
> 
> On Tue, 03 Nov 2026 06:44:57 +0000, Wentao Liang wrote:
>> The merge order test creates an array and a chain as inputs to
>> dma_fence_unwrap_merge(). The merge takes references to the underlying
>> fences but does not consume the input containers. The success path only
>> puts the merged result, leaking both the input array and the outer chain,
>> which owns the inner chain.
>>
>> Put the outer chain after checking the merged result and fall through to
>> the existing array cleanup on success as well as failure.
>>
>> The dma-buf-fence-unwrap KUnit suite passes all 11 tests under UML.
>>

>> Fixes: b1cce631e61f ("dma-buf: add selftest for fence order after merge")
>> Cc: stable@xxxxxxxxxxxxxxx

Completely agree to what Krzysztof wrote below, but additionally a <256 byte memory leak in a non-production unit test is not something I would consider relevant for backporting.

Unless Greg or Sasha have different opinions please don't automatically send everything with CC stable@xxxxxxxxxxxxxxx.

Regards,
Christian.

>> Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex
>> Signed-off-by: Wentao Liang <vulab@xxxxxxxxxxx>
>> ---
>>  drivers/dma-buf/st-dma-fence-unwrap.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
> 
> 
> 
> Multiple things here:
> 1. Your team ignored completely previous feedback. Multiple times.
> 
> 2. You use multiple identities with this email, thus I doubt
>    that we speak with an actual person.
> 
> 3. Your bot does not even bother running checkpatch, right?
> 
> 4. Nothing of this was reproduced nor tested.
> 
> 5. Finally, the same feedback:
> You sent multiple independent patches, to multiple independent
> subsystems. The amount of these patches clearly suggest this was
> AI generated and most likely not tested.
> 
> More importantly, you sent all this work without properly organizing
> relevant patches into patchsets. This makes reviewing difficult
> and might cause multiple reviewers to address the same issue.
> Replying to the entire set is impossible and requires handling each
> patch independently, instead of applying or discarding the set.
> Maintainers also won't see the bigger picture of your work. Quite
> worrying.
> 
> This is on the verge of hostile patch: bomb us with so many
> contributions, we won't be able to handle them in efficient manner,
> like responding ONCE to ask you to slow down.  Considering all this
> is untested and LLM generated, I have even more doubts whether this
> should be considered for review.
> 
> Please read kernel documentation BEFORE posting more work. It will
> explain you how to identify subsystems, how to organize your work per
> subsystem (so a patchset grouping multiple patches with a short cover
> letter), how to document usage of LLM and what you should not do
> if this was posted in a good faith.
> 
> Best regards,
> Krzysztof
> 
> 
> 
>