Re: [PATCH] scsi: libfc: fix directory server rport memory leak

[Krzysztof Kozlowski]

On 21/09/2026 17:15, krzk@xxxxxxxxxx wrote:
> 
> On Sun, 20 Sep 2026 01:34:05 +0800, Guangshuo Li wrote:
>> fc_rport_recv_plogi_req() creates an rport before allocating the frame
>> used for the PLOGI LS_ACC response.
>>
>> fc_rport_create() does not add FC_FID_DIR_SERV rports to the discovery
>> rport list. If fc_frame_alloc() fails while handling a PLOGI from the
>> directory server, the function returns without starting the rport state
>> machine or dropping the initial rport reference.
>>
>> Since the directory server rport is not present in the discovery list,
>> there is no later teardown path that can find the object and release
>> that reference. The allocated fc_rport_priv is therefore leaked.
>>
>> Record when the failed frame allocation leaves an unlisted directory
>> server rport behind and drop its initial reference after releasing the
>> rport mutex. Keep the existing lifetime unchanged for ordinary rports,
>> which remain owned by the discovery list.
>>
>> The issue was identified by a static analysis tool I developed and
>> confirmed by manual review.
>>
>> Fixes: 3ac6f98f4113 ("[SCSI] libfc: correctly handle incoming PLOGI request.")
>> Cc: stable@xxxxxxxxxxxxxxx
>> Signed-off-by: Guangshuo Li <lgs201920130244@xxxxxxxxx>
>> ---
>>  drivers/scsi/libfc/fc_rport.c | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
> 
> 
> 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, how to document usage of LLM and how what you should not
> do if this was posted in a good faith.
> 

Apologies for spamming here. Fighting fire with fire :). No, just mutt
mistake on my side.

Best regards,
Krzysztof