Re: [PATCH] RDMA/qedr: Unwind user queue setup if doorbell recovery setup fails

[Leon Romanovsky <leon@kernel.org>]

On Tue, Nov 03, 2026 at 10:21:41AM +0100, Krzysztof Kozlowski wrote:
> 
> On Tue, 03 Nov 2026 08:17:32 +0000, Wentao Liang wrote:
> > qedr_init_user_queue() pins user memory and allocates its PBL before
> > initializing the doorbell recovery record. If the last step fails, it
> > returns directly without releasing either resource. The CQ and QP
> > creation callers treat this as a failed queue initialization and do not
> > release that queue, leaving its user pages pinned and PBL storage leaked.
> > 
> > Free the PBL on doorbell recovery setup failure, then use the existing
> > umem cleanup. Match the PBL allocation mode: RoCE uses the populated PBL
> > allocator, while the other path allocates only the table descriptor.
> > Clear the freed pointer as well.
> > 
> > Fixes: 97f612509294 ("RDMA/qedr: Add doorbell overflow recovery support")
> > 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/qedr/verbs.c | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> 
> 
> 
> 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.

Same, dropping it.

Thanks