From: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
To: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>,
Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>,
ath12k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org, jjohnson@kernel.org,
baochen.qiang@oss.qualcomm.com,
vasanthakumar.thiagarajan@oss.qualcomm.com
Subject: Re: [PATCH ath-next v2] wifi: ath12k: Fix NAPI resource leaks in AHB external IRQ paths
Date: Fri, 9 Oct 2026 13:41:47 -0700 [thread overview]
Message-ID: <a3b513c2-24e1-4f4f-bf40-6494ebf2bb99@oss.qualcomm.com> (raw)
In-Reply-To: <2d52c324-59e3-411a-8012-e530426eed3a@oss.qualcomm.com>
On 10/8/2026 8:38 PM, Aaradhana Sahu wrote:
> On 10/8/2026 10:46 PM, Rameshkumar Sundaram wrote:
>> On 10/1/2026 10:24 AM, Aaradhana Sahu wrote:
>>> @@ -622,8 +642,10 @@ static int ath12k_ahb_config_ext_irq(struct ath12k_base *ab)
>>> irq_grp->grp_id = i;
>>> irq_grp->napi_ndev = alloc_netdev_dummy(0);
>>> - if (!irq_grp->napi_ndev)
>>> - return -ENOMEM;
>>> + if (!irq_grp->napi_ndev) {
>>> + ret = -ENOMEM;
>>> + goto free_napi_ndev;
>>> + }
>>> netif_napi_add(irq_grp->napi_ndev, &irq_grp->napi,
>>> ath12k_ahb_ext_grp_napi_poll);
>>> @@ -675,12 +697,19 @@ static int ath12k_ahb_config_ext_irq(struct ath12k_base *ab)
>>
>>
>> platform_get_irq_byname() can return a negative error code. Should we handle that explicitly before calling devm_request_irq()?
>>
>> Something like:
>>
>> irq = platform_get_irq_byname(ab->pdev, irq_name[irq_idx]);
>> if (irq < 0) {
>> ath12k_warn(ab, "failed to retrieve irq number for %s\n", irq_name[irq_idx]);
>> ret = irq;
>> ath12k_ahb_free_napi_for_group(irq_grp);
>> goto free_napi_ndev;
>> }
>>
>
> You're right, thanks for pointing this out. This patch focuses on fixing the NAPI resource leaks.
> Since handling the IRQ retrieval error is an existing issue, would it be okay to address it in a
> separate patch?
Yes, please handle as a separate patch.
My review agent notes:
There are three platform_get_irq_byname() call sites in ahb.c:
┌──────┬────────────────────────────────┬─────────────────────────────────┐
│ Line │ Location │ Checks return value? │
├──────┼────────────────────────────────┼─────────────────────────────────┤
│ 692 │ ext IRQ loop │ No │
│ │ (ath12k_ahb_config_ext_irq) │ │
├──────┼────────────────────────────────┼─────────────────────────────────┤
│ 730 │ CE IRQ loop │ No │
│ │ (ath12k_ahb_config_irq) │ │
├──────┼────────────────────────────────┼─────────────────────────────────┤
│ │ │ Yes — if │
│ 819 │ userpd IRQ │ (ab_ahb->userpd_irq_num[i] < 0) │
│ │ │ return ... │
└──────┴────────────────────────────────┴─────────────────────────────────┘
So the driver is already inconsistent: userpd checks, CE and ext don't.
That said, the ext and CE sites aren't silently broken — devm_request_irq()
with a negative IRQ number hits irq_to_desc(), gets NULL, and returns -EINVAL,
which the existing if (ret) check catches. The practical impact is a
confusing error message ("failed request_irq") when the real failure was
platform_get_irq_byname() itself.
And further suggest it should be a separate patch. The reasons:
1. This bug is pre-existing at both line 692 and line 730 — it wasn't
introduced by the NAPI leak patch. Adding the check to only line 692 (as the
reviewer suggests) leaves line 730 unfixed and makes the code more
inconsistent than before.
2. A correct fix needs to cover both sites together, with a consistent error
message and error-path handling.
3. This patch already has a well-defined scope (NAPI cleanup). Adding
unrelated error-handling hygiene muddies the Fixes: attribution and makes it
harder to backport.
>
>>
>>> ath12k_ahb_ext_interrupt_handler,
>>> IRQF_TRIGGER_RISING,
>>> irq_name[irq_idx], irq_grp);
>>> - if (ret)
>>> + if (ret) {
>>> ath12k_warn(ab, "failed request_irq for %d\n", irq);
>>> + ath12k_ahb_free_napi_for_group(irq_grp);
>>> + goto free_napi_ndev;
>>> + }
>>> }
>>> }
>>> return 0;
>>> +
>>> +free_napi_ndev:
>>> + ath12k_ahb_free_napi(ab, i);
>>> + return ret;
>>> }
>>> static int ath12k_ahb_config_irq(struct ath12k_base *ab)
next prev parent reply other threads:[~2026-10-09 20:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 4:54 [PATCH ath-next v2] wifi: ath12k: Fix NAPI resource leaks in AHB external IRQ paths Aaradhana Sahu
2026-10-08 17:16 ` Rameshkumar Sundaram
2026-10-09 3:38 ` Aaradhana Sahu
2026-10-09 20:41 ` Jeff Johnson [this message]
2026-10-12 9:19 ` Aaradhana Sahu
2026-10-09 20:17 ` Jeff Johnson
2026-10-12 15:00 ` Jeff Johnson
2026-10-12 6:35 ` Baochen Qiang
2026-10-12 8:59 ` Rameshkumar Sundaram
2026-10-13 1:05 ` 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=a3b513c2-24e1-4f4f-bf40-6494ebf2bb99@oss.qualcomm.com \
--to=jeff.johnson@oss.qualcomm.com \
--cc=aaradhana.sahu@oss.qualcomm.com \
--cc=ath12k@lists.infradead.org \
--cc=baochen.qiang@oss.qualcomm.com \
--cc=jjohnson@kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rameshkumar.sundaram@oss.qualcomm.com \
--cc=vasanthakumar.thiagarajan@oss.qualcomm.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