From: Ali Ahmet Memis <ali@iusegentoo.com>
To: "Martin K . Petersen" <martin.petersen@oracle.com>,
Ram Vegesna <ram.vegesna@broadcom.com>,
"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 0/5] scsi: elx: efct: fix resources stranded on failure paths
Date: Thu, 6 Aug 2026 19:23:40 +0000 [thread overview]
Message-ID: <20260806192345.328621-1-ali@iusegentoo.com> (raw)
Five places in efct take a resource and then return an error without
giving it back. Three of them lose an entry from a fixed size pool, which
stops the driver working once the pool is empty rather than growing
memory; the other two are ordinary leaks.
1 efct_els_hw_srrs_send() checks hw->state after taking an HIO
2 the WQE builders in efct_els_hw_srrs_send() and efct_hw_bls_send()
3 the WQE builder in efct_hw_send_frame(), which loses a request tag
4 efct_hw_rx_buffer_alloc() drops the coherent buffers it mapped
5 efct_hw_setup() leaves its two mempools behind
Patch 5 is the one I could exercise. Binding the driver to a PCI device
that is not an SLI-4 adapter makes sli_setup() fail after the mempools
have been created, and efct_pci_probe() then frees the struct efct that
held the only pointers to them. Repeating that probe 61 times under
CONFIG_DEBUG_KMEMLEAK:
before 1566 unreferenced objects, every one from efct_hw_setup()
after none, and the probe still fails the same way
Patches 1 to 4 are reasoned from the code. They need a real Emulex SLI-4
adapter, and for 1 to 3 a live FC link as well, which I do not have. Each
patch builds on its own.
I deliberately left the efct_hw_wq_write() failure paths alone.
efct_hw_wq_write() appends to wq->pending_list and drains from the head,
so it can return an error while this request is still linked there.
Releasing the HIO or the request tag at that point would leave a later
completion looking at something that has been handed back, which needs
more than a free on the error path.
Also not addressed here: efct_xport_attach() and efct_xport_initialize()
return without efct_hw_teardown() on some paths, and efcport_init() leaves
its first two pools behind when the third allocation fails. Those cross
two modules and I would rather send them separately once this is settled.
Ali Ahmet Memis (5):
scsi: elx: efct: check the HW state before allocating an HIO
scsi: elx: efct: free the HIO when the WQE cannot be built
scsi: elx: efct: free the request tag when the send frame WQE fails
scsi: elx: efct: free the RQ buffers already allocated when one fails
scsi: elx: efct: destroy the mailbox pools when setup fails
drivers/scsi/elx/efct/efct_hw.c | 71 +++++++++++++++++++++------------
1 file changed, 45 insertions(+), 26 deletions(-)
base-commit: 0d839570765118029aa8bf4a95444c6a11aacf85
--
2.55.0
next reply other threads:[~2026-08-06 19:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 19:23 Ali Ahmet Memis [this message]
2026-08-06 19:23 ` [PATCH 1/5] scsi: elx: efct: check the HW state before allocating an HIO Ali Ahmet Memis
2026-08-06 19:44 ` sashiko-bot
2026-08-06 19:23 ` [PATCH 2/5] scsi: elx: efct: free the HIO when the WQE cannot be built Ali Ahmet Memis
2026-08-06 19:54 ` sashiko-bot
2026-08-06 19:23 ` [PATCH 3/5] scsi: elx: efct: free the request tag when the send frame WQE fails Ali Ahmet Memis
2026-08-06 19:50 ` sashiko-bot
2026-08-06 19:23 ` [PATCH 4/5] scsi: elx: efct: free the RQ buffers already allocated when one fails Ali Ahmet Memis
2026-08-06 20:00 ` sashiko-bot
2026-08-06 19:23 ` [PATCH 5/5] scsi: elx: efct: destroy the mailbox pools when setup fails Ali Ahmet Memis
2026-08-06 19:41 ` sashiko-bot
2026-08-06 20:22 ` [PATCH v2 0/5] scsi: elx: efct: fix resources stranded on failure paths Ali Ahmet Memis
2026-08-06 20:22 ` [PATCH v2 1/5] scsi: elx: efct: check the HW state before allocating an HIO Ali Ahmet Memis
2026-08-06 20:59 ` sashiko-bot
2026-08-06 20:22 ` [PATCH v2 2/5] scsi: elx: efct: free the HIO when the WQE cannot be built Ali Ahmet Memis
2026-08-06 20:52 ` sashiko-bot
2026-08-06 20:22 ` [PATCH v2 3/5] scsi: elx: efct: free the request tag when the send frame WQE fails Ali Ahmet Memis
2026-08-06 20:41 ` sashiko-bot
2026-08-06 20:22 ` [PATCH v2 4/5] scsi: elx: efct: free the RQ buffers already allocated when one fails Ali Ahmet Memis
2026-08-06 20:38 ` sashiko-bot
2026-08-06 20:22 ` [PATCH v2 5/5] scsi: elx: efct: destroy the mailbox pools when setup fails Ali Ahmet Memis
2026-08-06 20:57 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260806192345.328621-1-ali@iusegentoo.com \
--to=ali@iusegentoo.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ram.vegesna@broadcom.com \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox