Re: [PATCH] RDMA/hfi1: Free the trap send buffer when no address handle is available

[Leon Romanovsky <leon@kernel.org>]

On Tue, Nov 03, 2026 at 10:21:38AM +0100, Krzysztof Kozlowski wrote:
> 
> On Tue, 03 Nov 2026 08:19:15 +0000, Wentao Liang wrote:
> > send_trap() allocates a MAD send buffer before checking the subnet
> > manager address handle. If creating that handle fails, or if the subnet
> > manager LID is permissive, it unlocks and returns without submitting or
> > freeing the buffer. No send completion can release an unsubmitted MAD.
> > 
> > Free the send buffer after releasing the lock on both early returns,
> > matching the other failures after ib_create_send_mad().
> > 
> > Fixes: bf90aadd630c ("IB/hfi1: Send MAD traps until repressed")
> > Cc: stable@vger.kernel.org
> > Assisted-by: DeepSeek-V4.1-Flash and OpenAI Codex
> > Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> > ---
> >  drivers/infiniband/hw/hfi1/mad.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> 
> 
> 
> Multiple things here:
> 1. Your team ignored completely previous feedback. Multiple times.
> 
> 2. You use multiple identities with this email address, 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.

Thanks, we will simply drop this patch. It is not worth to review it.

Thanks