In lpfc_config_port_post(), pmb is allocated via mempool_alloc() but
is not freed when lpfc_readl() fails.

Fix this by adding mempool_free() in the error path.

Fixes: 9940b97bb30d ("[SCSI] lpfc 8.3.22: Add support for PCI Adapter Failure")
Co-developed-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
---
 drivers/scsi/lpfc/lpfc_init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index b1460b16dd91..bc2e55f6a50f 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -572,6 +572,7 @@ lpfc_config_port_post(struct lpfc_hba *phba)
 	/* Enable appropriate host interrupts */
 	if (lpfc_readl(phba->HCregaddr, &status)) {
 		spin_unlock_irq(&phba->hbalock);
+		mempool_free(pmb, phba->mbox_mem_pool);
 		return -EIO;
 	}
 	status |= HC_MBINT_ENA | HC_ERINT_ENA | HC_LAINT_ENA;
-- 
2.34.1

…
> Fix this by adding mempool_free() in the error path.

Please avoid duplicate source code here.
https://elixir.bootlin.com/linux/v6.19-rc2/source/drivers/scsi/lpfc/lpfc_init.c#L563-L564


See also:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc3#n262

Regards,
Markus

On Mon, Dec 29, 2025 at 10:09:04AM +0100, Markus Elfring wrote:
> …
> > Fix this by adding mempool_free() in the error path.
> 
> Please avoid duplicate source code here.
> https://elixir.bootlin.com/linux/v6.19-rc2/source/drivers/scsi/lpfc/lpfc_init.c#L563-L564

Thanks for pointing this out. I will use a goto label to unify the error 
handling logic and avoid code duplication in v2.

> See also:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc3#n262
> 
> Regards,
> Markus

Regarding the stable kernel rules, do you consider this bug severe enough 
to warrant a Cc: stable tag? Since this error path is unlikely to be 
triggered during normal operation and the leak is small, I didn't think 
it was critical enough to bother the stable maintainers.

Thanks,
Zilin Guan

On Tue, Dec 30, 2025 at 06:20:08AM +0000, Zilin Guan wrote:
> On Mon, Dec 29, 2025 at 10:09:04AM +0100, Markus Elfring wrote:
> > …
> > > Fix this by adding mempool_free() in the error path.
> > 
> > Please avoid duplicate source code here.
> > https://elixir.bootlin.com/linux/v6.19-rc2/source/drivers/scsi/lpfc/lpfc_init.c#L563-L564
> 
> Thanks for pointing this out. I will use a goto label to unify the error 
> handling logic and avoid code duplication in v2.
> 
> > See also:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc3#n262
> > 
> > Regards,
> > Markus
> 
> Regarding the stable kernel rules, do you consider this bug severe enough 
> to warrant a Cc: stable tag? Since this error path is unlikely to be 
> triggered during normal operation and the leak is small, I didn't think 
> it was critical enough to bother the stable maintainers.

I don't agree with either of Markus's review comments.  People have
asked him to stop reviewing code or at least to stick to pointing out
bugs or complaining about style and grammar issues but he doesn't
listen.

https://lore.kernel.org/all/2025121108-armless-earthling-7a6f@gregkh/

regards,
dan carpenter

On Mon, Jan 05, 2026 at 12:53:40PM +0300, Dan Carpenter wrote:
> On Tue, Dec 30, 2025 at 06:20:08AM +0000, Zilin Guan wrote:
> > On Mon, Dec 29, 2025 at 10:09:04AM +0100, Markus Elfring wrote:
> > > …
> > > > Fix this by adding mempool_free() in the error path.
> > > 
> > > Please avoid duplicate source code here.
> > > https://elixir.bootlin.com/linux/v6.19-rc2/source/drivers/scsi/lpfc/lpfc_init.c#L563-L564
> > 
> > Thanks for pointing this out. I will use a goto label to unify the error 
> > handling logic and avoid code duplication in v2.
> > 
> > > See also:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc3#n262
> > > 
> > > Regards,
> > > Markus
> > 
> > Regarding the stable kernel rules, do you consider this bug severe enough 
> > to warrant a Cc: stable tag? Since this error path is unlikely to be 
> > triggered during normal operation and the leak is small, I didn't think 
> > it was critical enough to bother the stable maintainers.
> 
> I don't agree with either of Markus's review comments.  People have
> asked him to stop reviewing code or at least to stick to pointing out
> bugs or complaining about style and grammar issues but he doesn't
> listen.

I meant "or at least stop complaining about style and grammar issues".

regards,
dan carpenter

> I meant "or at least stop complaining about style and grammar issues".

Do any other contributors occasionally get also into the mood to point similar
adjustment opportunities out?

Regards,
Markus

>> See also:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc3#n262
…
> Regarding the stable kernel rules, do you consider this bug severe enough 
> to warrant a Cc: stable tag?

I suggest to take another look at information from previous discussions on
severity filters.


>                              Since this error path is unlikely to be 
> triggered during normal operation and the leak is small,

It seems that basic data processing was not hindered so far by the affected
function implementation.


>                                                          I didn't think 
> it was critical enough to bother the stable maintainers.

The tag “Fixes” is also an indication for related development considerations,
isn't it?

Regards,
Markus

> I suggest to take another look at information from previous discussions on
> severity filters.
> ...
> It seems that basic data processing was not hindered so far by the affected
> function implementation.
> ...
> The tag “Fixes” is also an indication for related development considerations,
> isn't it?

Thanks for the clarification.

I agree that the "Fixes" tag provides sufficient context for tracking. 
Given that the bug does not impact basic functionality, I will rely 
on the "Fixes" tag and leave the backporting decision to the stable 
maintainers' discretion, rather than explicitly adding the "Cc: stable".

I will send out v2 with the code refactoring (using goto) shortly.

Regards,
Zilin Guan