From: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
To: ZhaoJinming <zhaojinming@uniontech.com>,
Baochen Qiang <baochen.qiang@oss.qualcomm.com>,
Jeff Johnson <jjohnson@kernel.org>,
Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Cc: linux-wireless@vger.kernel.org, ath11k@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8] wifi: ath11k: fix resource leak on error in ext IRQ setup
Date: Wed, 29 Jul 2026 18:24:27 -0700 [thread overview]
Message-ID: <5ba0a5c3-7009-4e9f-b5b0-11ec79469451@oss.qualcomm.com> (raw)
In-Reply-To: <20260729020005.219253-1-zhaojinming@uniontech.com>
On 7/28/2026 7:00 PM, ZhaoJinming wrote:
> In ath11k_ahb_config_irq(), when a CE request_irq() fails, the function
> returns the error immediately without freeing the CE IRQs that were
> successfully registered in previous loop iterations. The probe error
> path does not call ath11k_ahb_free_irq() either, so the previously
> registered CE IRQ handlers remain attached to the interrupt lines and
> are never released.
>
> In ath11k_ahb_config_ext_irq(), when an external request_irq() fails,
> the error is only logged and the loop continues. The function then
> returns 0 indicating success, leaving the device in a partially
> configured state where some external IRQs are not registered. This
> causes enable_irq()/disable_irq()/free_irq() to be called on
> unregistered IRQs during runtime and remove/shutdown, triggering
> WARN_ON(!desc->action), and missing interrupt handlers lead to data
> loss.
>
> Additionally, if alloc_netdev_dummy() fails for a later IRQ group, the
> function returns -ENOMEM without freeing the ext IRQs and napi_ndev
> that were successfully set up for earlier groups.
>
> Fix all three issues: propagate the error up to the caller and unwind
> all successfully registered IRQs and allocated resources on failure.
> Also move ab->irq_num[irq_idx] assignment after request_irq() succeeds
> in the ext IRQ path to match the CE IRQ path and avoid storing a stale
> IRQ number on failure.
>
Is there a reason you didn't carry forward Baochen's Reviewed-by: tag?
He first gave the the tag for v4
In v5 the code was unchanged, and Baochen commented:
I have given my Reviewed-by: tag in the v4 review. Since v5 is identical to v4
you should pick it.
once again:
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
v6 was a trivial change in code. If you had applied his Reviewed-by then I
would have maintained it for v6. if it had been a bigger diff then it might be
ok to drop the Reviewed-by, but you'd then want to mention that in the commit
history
v7 was unchanged from v6 so it should have had Baochen's RB.
code in v8 was unchanged from v7 so it should have had Baochen's RB.
This is another good reason to use b4 for patch maintenance.
"b4 trailers -u" will accumulate any tags and update your patch.
That is all advice for next time.
You don't need to post another version to pick up the RB tag.
Running b4 in maintainer mode will pick up the one I just added above.
Baochen, no need to re-review.
Ramesh, would like you to review.
/jeff
next prev parent reply other threads:[~2026-07-30 1:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 2:00 ZhaoJinming
2026-07-30 1:24 ` Jeff Johnson [this message]
2026-07-30 9:40 ` Rameshkumar Sundaram
2026-07-30 9:33 ` Rameshkumar Sundaram
2026-07-31 14:41 ` Jeff Johnson
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=5ba0a5c3-7009-4e9f-b5b0-11ec79469451@oss.qualcomm.com \
--to=jeff.johnson@oss.qualcomm.com \
--cc=ath11k@lists.infradead.org \
--cc=baochen.qiang@oss.qualcomm.com \
--cc=jjohnson@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rameshkumar.sundaram@oss.qualcomm.com \
--cc=zhaojinming@uniontech.com \
/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
all inboxes | Powered by JetHome®