* Re: [PATCH 15/61] trace: Prefer IS_ERR_OR_NULL over manual NULL check
From: Steven Rostedt @ 2026-03-10 14:07 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Masami Hiramatsu, Mathieu Desnoyers
In-Reply-To: <20260310-b4-is_err_or_null-v1-15-bd63b656022d@avm.de>
On Tue, 10 Mar 2026 12:48:41 +0100
Philipp Hahn <phahn-oss@avm.de> wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
Why?
>
> Change generated with coccinelle.
>
> To: Steven Rostedt <rostedt@goodmis.org>
> To: Masami Hiramatsu <mhiramat@kernel.org>
> To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-trace-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> kernel/trace/fprobe.c | 2 +-
> kernel/trace/kprobe_event_gen_test.c | 2 +-
> kernel/trace/trace_events_hist.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c
> index dcadf1d23b8a31f571392d0c49cbd22df1716b4f..a94ce810d83b90f55d1178a9bd29c78fd068df4c 100644
> --- a/kernel/trace/fprobe.c
> +++ b/kernel/trace/fprobe.c
> @@ -607,7 +607,7 @@ static int fprobe_module_callback(struct notifier_block *nb,
> do {
> rhashtable_walk_start(&iter);
>
> - while ((node = rhashtable_walk_next(&iter)) && !IS_ERR(node))
> + while (!IS_ERR_OR_NULL((node = rhashtable_walk_next(&iter))))
Ug, No!
That looks so much worse than the original.
-- Steve
> fprobe_remove_node_in_module(mod, node, &alist);
>
> rhashtable_walk_stop(&iter);
> diff --git a/kernel/trace/kprobe_event_gen_test.c b/kernel/trace/kprobe_event_gen_test.c
> index 5a4b722b50451bfdee42769a6d3be39c055690d1..a1735ca273f0b756aa1fcfcdab30ddad9bc51c5f 100644
> --- a/kernel/trace/kprobe_event_gen_test.c
> +++ b/kernel/trace/kprobe_event_gen_test.c
> @@ -75,7 +75,7 @@ static struct trace_event_file *gen_kretprobe_test;
>
> static bool trace_event_file_is_valid(struct trace_event_file *input)
> {
> - return input && !IS_ERR(input);
> + return !IS_ERR_OR_NULL(input);
> }
>
> /*
> diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
> index 73ea180cad555898693e92ee397a1c9493c7c167..59df215e1dfd9349eca1c0823ed709ec7285f766 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -3973,7 +3973,7 @@ trace_action_create_field_var(struct hist_trigger_data *hist_data,
> */
> field_var = create_target_field_var(hist_data, system, event, var);
>
> - if (field_var && !IS_ERR(field_var)) {
> + if (!IS_ERR_OR_NULL(field_var)) {
> save_field_var(hist_data, field_var);
> hist_field = field_var->var;
> } else {
>
^ permalink raw reply
* Re: [PATCH 00/61] treewide: Use IS_ERR_OR_NULL over manual NULL check - refactor
From: Steven Rostedt @ 2026-03-10 14:14 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Julia Lawall, Nicolas Palix, Chris Mason,
David Sterba, Ilya Dryomov, Alex Markuze, Viacheslav Dubeyko,
Theodore Ts'o, Andreas Dilger, Steve French, Paulo Alcantara,
Ronnie Sahlberg, Shyam Prasad N, Tom Talpey, Bharath SM,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Miklos Szeredi,
Konstantin Komarov, Andreas Gruenbacher, Kees Cook, Tony Luck,
Guilherme G. Piccoli, Jan Kara, Phillip Lougher, Alexander Viro,
Christian Brauner, Jan Kara, Masami Hiramatsu, Mathieu Desnoyers,
Tejun Heo, David Vernet, Andrea Righi, Changwoo Min, Ingo Molnar,
Peter Zijlstra, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Ben Segall, Mel Gorman, Valentin Schneider, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
Sylwester Nawrocki, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Max Filippov, Paolo Bonzini, John Johansen,
Paul Moore, James Morris, Serge E. Hallyn, Andrew Morton,
Alasdair Kergon, Mike Snitzer, Mikulas Patocka,
Benjamin Marzinski, David S. Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, Jamal Hadi Salim, Jiri Pirko,
Marcelo Ricardo Leitner, Xin Long, Trond Myklebust,
Anna Schumaker, Chuck Lever, Jeff Layton, NeilBrown,
Olga Kornievskaia, Dai Ngo, Jon Maloy, Johannes Berg,
Catalin Marinas, Russell King, John Crispin, Thomas Bogendoerfer,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Zhenyu Wang,
Zhi Wang, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Alex Deucher, Christian König, Sandy Huang,
Heiko Stübner, Andy Yan, Igor Russkikh, Andrew Lunn,
Pavan Chebbi, Michael Chan, Potnuri Bharat Teja, Tony Nguyen,
Przemek Kitszel, Taras Chornyi, Maxime Coquelin, Alexandre Torgue,
Iyappan Subramanian, Keyur Chudgar, Quan Nguyen, Heiner Kallweit,
Marc Zyngier, Thomas Gleixner, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vinod Koul, Linus Walleij, Ulf Hansson,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Martin K. Petersen,
Eduardo Valentin, Keerthy, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Alex Williamson, Mark Greer,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Shuah Khan, Kieran Bingham, Mauro Carvalho Chehab, Joerg Roedel,
Will Deacon, Robin Murphy, Lee Jones, Pavel Machek, Dave Penkler,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Justin Sanders, Jens Axboe, Georgi Djakov, Michael Turquette,
Stephen Boyd, Philipp Zabel, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Pali Rohár, Dmitry Torokhov
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
On Tue, 10 Mar 2026 12:48:26 +0100
Philipp Hahn <phahn-oss@avm.de> wrote:
> While doing some static code analysis I stumbled over a common pattern,
> where IS_ERR() is combined with a NULL check. For that there is
> IS_ERR_OR_NULL().
>
> I've written a Coccinelle patch to find and patch those instances.
> The patches follow grouped by subsystem.
Honestly, the IS_ERR_OR_NULL() looks worse in a lot of the locations you
updated. Just because we have IS_ERR_OR_NULL() doesn't mean we need to go
and replace every location that can use it.
NAK for any code this touches that I'm responsible for.
-- Steve
^ permalink raw reply
* Re: [PATCH 00/61] treewide: Use IS_ERR_OR_NULL over manual NULL check - refactor
From: Theodore Tso @ 2026-03-10 14:23 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Julia Lawall, Nicolas Palix, Chris Mason,
David Sterba, Ilya Dryomov, Alex Markuze, Viacheslav Dubeyko,
Andreas Dilger, Steve French, Paulo Alcantara, Ronnie Sahlberg,
Shyam Prasad N, Tom Talpey, Bharath SM, Eric Van Hensbergen,
Latchesar Ionkov, Dominique Martinet, Christian Schoenebeck,
Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu, Sandeep Dhavale, Hongbo Li,
Chunhai Guo, Miklos Szeredi, Konstantin Komarov,
Andreas Gruenbacher, Kees Cook, Tony Luck, Guilherme G. Piccoli,
Jan Kara, Phillip Lougher, Alexander Viro, Christian Brauner,
Jan Kara, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Tejun Heo, David Vernet, Andrea Righi, Changwoo Min, Ingo Molnar,
Peter Zijlstra, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Ben Segall, Mel Gorman, Valentin Schneider, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
Sylwester Nawrocki, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Max Filippov, Paolo Bonzini, John Johansen,
Paul Moore, James Morris, Serge E. Hallyn, Andrew Morton,
Alasdair Kergon, Mike Snitzer, Mikulas Patocka,
Benjamin Marzinski, David S. Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, Jamal Hadi Salim, Jiri Pirko,
Marcelo Ricardo Leitner, Xin Long, Trond Myklebust,
Anna Schumaker, Chuck Lever, Jeff Layton, NeilBrown,
Olga Kornievskaia, Dai Ngo, Jon Maloy, Johannes Berg,
Catalin Marinas, Russell King, John Crispin, Thomas Bogendoerfer,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Zhenyu Wang,
Zhi Wang, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Alex Deucher, Christian König, Sandy Huang,
Heiko Stübner, Andy Yan, Igor Russkikh, Andrew Lunn,
Pavan Chebbi, Michael Chan, Potnuri Bharat Teja, Tony Nguyen,
Przemek Kitszel, Taras Chornyi, Maxime Coquelin, Alexandre Torgue,
Iyappan Subramanian, Keyur Chudgar, Quan Nguyen, Heiner Kallweit,
Marc Zyngier, Thomas Gleixner, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vinod Koul, Linus Walleij, Ulf Hansson,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Martin K. Petersen,
Eduardo Valentin, Keerthy, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Alex Williamson, Mark Greer,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Shuah Khan, Kieran Bingham, Mauro Carvalho Chehab, Joerg Roedel,
Will Deacon, Robin Murphy, Lee Jones, Pavel Machek, Dave Penkler,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Justin Sanders, Jens Axboe, Georgi Djakov, Michael Turquette,
Stephen Boyd, Philipp Zabel, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Pali Rohár, Dmitry Torokhov
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
On Tue, Mar 10, 2026 at 12:48:26PM +0100, Philipp Hahn wrote:
> While doing some static code analysis I stumbled over a common pattern,
> where IS_ERR() is combined with a NULL check. For that there is
> IS_ERR_OR_NULL().
>
> I've written a Coccinelle patch to find and patch those instances.
> The patches follow grouped by subsystem.
I'm going to gently suggest that you *not* try to do this as a
tree-wide change, since we don't need to change some interface
requiring a global, flag day change. This is instead a cleanup, which
maybe makes the code slightly better, but which also has a the
downside of breaking lots of inflight development patches by
potentially causing merge or patch conflicts.
So why don't you send it to each subsystem as a separate patch or
small patch series, instead of spamming a dozen-plus mailing lists,
are probably hundreds of developers, most of whom aren't going to
care about changs in some far flung part of the kernel?
Regards,
- Ted
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: avoid dynamic alloc when parsing wmi tb
From: Jeff Johnson @ 2026-03-10 14:39 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless
In-Reply-To: <DGZ0GMD3VS8R.2ZZLQNJGDDFLZ@gmail.com>
On 3/10/2026 2:56 AM, Nicolas Escande wrote:
> On Mon Mar 9, 2026 at 9:16 PM CET, Jeff Johnson wrote:
>> On 3/9/2026 8:20 AM, Nicolas Escande wrote:
>>> @@ -3913,7 +3903,7 @@ ath12k_wmi_obss_color_collision_event(struct ath12k_base *ab, struct sk_buff *sk
>>> u32 vdev_id, evt_type;
>>> u64 bitmap;
>>>
>>> - const void **tb __free(kfree) = ath12k_wmi_tlv_parse_alloc(ab, skb, GFP_ATOMIC);
>>> + const void **tb = ath12k_wmi_tlv_parse(ab, skb);
>>
>> checkpatch complains:
>> Missing a blank line after declarations
>
> Weird that my checkpatch (from yesterday's ath-next) did not catch this:
> scripts/checkpatch.pl \
> mail/0001-wifi-ath12k-avoid-dynamic-alloc-when-parsing-wmi-tb.patch
> total: 0 errors, 0 warnings, 0 checks, 807 lines checked
>
> Is there additionnal flags or tools I should run ?
The difference is I run it on the patches already merged in my workspace:
scripts/checkpatch.pl -g --codespell --ignore COMMIT_LOG_LONG_LINE,FILE_PATH_CHANGES,UNNECESSARY_PARENTHESES --terse --show-types $base..
^ permalink raw reply
* Re: [PATCH 17/61] module: Prefer IS_ERR_OR_NULL over manual NULL check
From: Aaron Tomlin @ 2026-03-10 14:45 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen
In-Reply-To: <20260310-b4-is_err_or_null-v1-17-bd63b656022d@avm.de>
[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]
On Tue, Mar 10, 2026 at 12:48:43PM +0100, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Luis Chamberlain <mcgrof@kernel.org>
> To: Petr Pavlu <petr.pavlu@suse.com>
> To: Daniel Gomez <da.gomez@kernel.org>
> To: Sami Tolvanen <samitolvanen@google.com>
> To: Aaron Tomlin <atomlin@atomlin.com>
> Cc: linux-modules@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> kernel/module/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index c3ce106c70af165e2dc1a3c79f5a074a5c3e3d34..7f62f0620dcd75960e431f7af3d1cadf4cc41e4b 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -1551,7 +1551,7 @@ static int simplify_symbols(struct module *mod, const struct load_info *info)
> case SHN_UNDEF:
> ksym = resolve_symbol_wait(mod, info, name);
> /* Ok if resolved. */
> - if (ksym && !IS_ERR(ksym)) {
> + if (!IS_ERR_OR_NULL(ksym)) {
> sym[i].st_value = kernel_symbol_value(ksym);
> break;
> }
>
> --
> 2.43.0
>
Hi Philipp,
Thank you.
Have you considered other users of IS_ERR() in kernel/module/main.c too?
Perhaps it might be best to prepare a clean up for each applicable
subsystem in isolation.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [EXTERNAL] [PATCH 38/61] net: Prefer IS_ERR_OR_NULL over manual NULL check
From: Elad Nachman @ 2026-03-10 15:07 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Igor Russkikh, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Pavan Chebbi, Michael Chan,
Potnuri Bharat Teja, Tony Nguyen, Przemek Kitszel, Taras Chornyi,
Maxime Coquelin, Alexandre Torgue, Iyappan Subramanian,
Keyur Chudgar, Quan Nguyen, Heiner Kallweit, Russell King
In-Reply-To: <20260310-b4-is_err_or_null-v1-38-bd63b656022d@avm.de>
>
>
> From: Philipp Hahn <phahn-oss@avm.de>
> Sent: Tuesday, March 10, 2026 1:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com; bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-devel@lists.linux.dev; dri-devel@lists.freedesktop.org; gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org; linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org; linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-module@vger.kernel.org; linux-sh@vger.kernel.org; linux-sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com; linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-wireless@vger.kernel.org; netdev@vger.kernel.org; ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn <phahn-oss@avm.de>
> Cc: Igor Russkikh <irusskikh@marvell.com>; Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Pavan Chebbi <pavan.chebbi@broadcom.com>; Michael Chan <mchan@broadcom.com>; Potnuri Bharat Teja <bharat@chelsio.com>; Tony Nguyen <anthony.l.nguyen@intel.com>; Przemek Kitszel <przemyslaw.kitszel@intel.com>; Taras Chornyi <taras.chornyi@plvision.eu>; Maxime Coquelin <mcoquelin.stm32@gmail.com>; Alexandre Torgue <alexandre.torgue@foss.st.com>; Iyappan Subramanian <iyappan@os.amperecomputing.com>; Keyur Chudgar <keyur@os.amperecomputing.com>; Quan Nguyen <quan@os.amperecomputing.com>; Heiner Kallweit <hkallweit1@gmail.com>; Russell King <linux@armlinux.org.uk>
> Subject: [EXTERNAL] [PATCH 38/61] net: Prefer IS_ERR_OR_NULL over manual NULL check
> ZjQcmQRYFpfptBannerEnd
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Igor Russkikh <mailto:irusskikh@marvell.com>
> To: Andrew Lunn <mailto:andrew+netdev@lunn.ch>
> To: "David S. Miller" <mailto:davem@davemloft.net>
> To: Eric Dumazet <mailto:edumazet@google.com>
> To: Jakub Kicinski <mailto:kuba@kernel.org>
> To: Paolo Abeni <mailto:pabeni@redhat.com>
> To: Pavan Chebbi <mailto:pavan.chebbi@broadcom.com>
> To: Michael Chan <mailto:mchan@broadcom.com>
> To: Potnuri Bharat Teja <mailto:bharat@chelsio.com>
> To: Tony Nguyen <mailto:anthony.l.nguyen@intel.com>
> To: Przemek Kitszel <mailto:przemyslaw.kitszel@intel.com>
> To: Taras Chornyi <mailto:taras.chornyi@plvision.eu>
> To: Maxime Coquelin <mailto:mcoquelin.stm32@gmail.com>
> To: Alexandre Torgue <mailto:alexandre.torgue@foss.st.com>
> To: Iyappan Subramanian <mailto:iyappan@os.amperecomputing.com>
> To: Keyur Chudgar <mailto:keyur@os.amperecomputing.com>
> To: Quan Nguyen <mailto:quan@os.amperecomputing.com>
> To: Heiner Kallweit <mailto:hkallweit1@gmail.com>
> To: Russell King <mailto:linux@armlinux.org.uk>
> Cc: mailto:netdev@vger.kernel.org
> Cc: mailto:linux-kernel@vger.kernel.org
> Cc: mailto:intel-wired-lan@lists.osuosl.org
> Cc: mailto:linux-stm32@st-md-mailman.stormreply.com
> Cc: mailto:linux-arm-kernel@lists.infradead.org
> Cc: mailto:linux-usb@vger.kernel.org
> Signed-off-by: Philipp Hahn <mailto:phahn-oss@avm.de>
> ---
> drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 2 +-
> drivers/net/ethernet/broadcom/tg3.c | 2 +-
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c | 3 +--
> drivers/net/ethernet/intel/ice/devlink/devlink.c | 2 +-
> drivers/net/ethernet/marvell/prestera/prestera_router.c | 2 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
> drivers/net/mdio/mdio-xgene.c | 2 +-
> drivers/net/usb/r8152.c | 2 +-
> 8 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> index e270327e47fd804cc8ee5cfd53ed1b993c955c41..43edef35c4b1ff606b2f1519a07fad4c9a990ad4 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> @@ -810,7 +810,7 @@ static int __aq_ring_xdp_clean(struct aq_ring_s *rx_ring,
> }
>
> skb = aq_xdp_run_prog(aq_nic, &xdp, rx_ring, buff);
> - if (IS_ERR(skb) || !skb)
> + if (IS_ERR_OR_NULL(skb))
> continue;
>
> if (ptp_hwtstamp_len > 0)
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 2328fce336447eb4a796f9300ccc0ab536ff0a35..8ed79f34f03d81184dcc12e6eaff009cb8f7756e 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -7943,7 +7943,7 @@ static int tg3_tso_bug(struct tg3 *tp, struct tg3_napi *tnapi,
>
> segs = skb_gso_segment(skb, tp->dev->features &
> ~(NETIF_F_TSO | NETIF_F_TSO6));
> - if (IS_ERR(segs) || !segs) {
> + if (IS_ERR_OR_NULL(segs)) {
> tnapi->tx_dropped++;
> goto tg3_tso_bug_end;
> }
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> index 3307e50426819087ad985178c4a5383f16b8e7b4..1c8a6445d4b2e3535d8f1b7908dd02d8dd2f23fa 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> @@ -1032,8 +1032,7 @@ static void ch_flower_stats_handler(struct work_struct *work)
> do {
> rhashtable_walk_start(&iter);
>
> - while ((flower_entry = rhashtable_walk_next(&iter)) &&
> - !IS_ERR(flower_entry)) {
> + while (!IS_ERR_OR_NULL((flower_entry = rhashtable_walk_next(&iter)))) {
> ret = cxgb4_get_filter_counters(adap->port[0],
> flower_entry->filter_id,
> &packets, &bytes,
> diff --git a/drivers/net/ethernet/intel/ice/devlink/devlink.c b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> index 6c72bd15db6d75a1d4fa04ef8fefbd26fb6e84bd..3d08b9187fd76ca3198af28111b6f1c1765ea01e 100644
> --- a/drivers/net/ethernet/intel/ice/devlink/devlink.c
> +++ b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> @@ -791,7 +791,7 @@ static void ice_traverse_tx_tree(struct devlink *devlink, struct ice_sched_node
> node->parent->rate_node);
> }
>
> - if (rate_node && !IS_ERR(rate_node))
> + if (!IS_ERR_OR_NULL(rate_node))
> node->rate_node = rate_node;
>
> traverse_children:
> diff --git a/drivers/net/ethernet/marvell/prestera/prestera_router.c b/drivers/net/ethernet/marvell/prestera/prestera_router.c
> index b036b173a308b5f994ad8538eb010fa27196988c..4492938e8a3da91d32efe8d45ccbe2eb437c0e49 100644
> --- a/drivers/net/ethernet/marvell/prestera/prestera_router.c
> +++ b/drivers/net/ethernet/marvell/prestera/prestera_router.c
> @@ -1061,7 +1061,7 @@ static void __prestera_k_arb_hw_state_upd(struct prestera_switch *sw,
> n = NULL;
> }
>
> - if (!IS_ERR(n) && n) {
> + if (!IS_ERR_OR_NULL(n)) {
> neigh_event_send(n, NULL);
> neigh_release(n);
> } else {
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 6827c99bde8c22db42b363d2d36ad6f26075ed50..356a4e9ce04b1fcf8786d7274d31ace404be2cf6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1275,7 +1275,7 @@ static int stmmac_init_phy(struct net_device *dev)
> /* Some DT bindings do not set-up the PHY handle. Let's try to
> * manually parse it
> */
> - if (!phy_fwnode || IS_ERR(phy_fwnode)) {
> + if (IS_ERR_OR_NULL(phy_fwnode)) {
> int addr = priv->plat->phy_addr;
> struct phy_device *phydev;
>
> diff --git a/drivers/net/mdio/mdio-xgene.c b/drivers/net/mdio/mdio-xgene.c
> index a8f91a4b7fed0927ee14e408000cd3a2bfb9b09a..09b30b563295c6085dc1358ac361301e5cf6b2a8 100644
> --- a/drivers/net/mdio/mdio-xgene.c
> +++ b/drivers/net/mdio/mdio-xgene.c
> @@ -265,7 +265,7 @@ struct phy_device *xgene_enet_phy_register(struct mii_bus *bus, int phy_addr)
> struct phy_device *phy_dev;
>
> phy_dev = get_phy_device(bus, phy_addr, false);
> - if (!phy_dev || IS_ERR(phy_dev))
> + if (IS_ERR_OR_NULL(phy_dev))
> return NULL;
>
> if (phy_device_register(phy_dev))
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 0c83bbbea2e7c322ee6339893e281237663bd3ae..73f17ebd7d40007eec5004f887a46249defd28ab 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -2218,7 +2218,7 @@ static void r8152_csum_workaround(struct r8152 *tp, struct sk_buff *skb,
>
> features &= ~(NETIF_F_SG | NETIF_F_IPV6_CSUM | NETIF_F_TSO6);
> segs = skb_gso_segment(skb, features);
> - if (IS_ERR(segs) || !segs)
> + if (IS_ERR_OR_NULL(segs))
> goto drop;
>
> __skb_queue_head_init(&seg_list);
>
> --
> 2.43.0
>
>
Acked-by: Elad Nachman <enachman@marvell.com>
^ permalink raw reply
* Re: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: LB F @ 2026-03-10 15:12 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CALdGYqQb=Vt0jjqW7k8RGMV1gczL0cg-26cHgCm3MmzBjezGMQ@mail.gmail.com>
Hi Ping-Ke,
Thank you for your guidance. To provide you with the cleanest possible
diagnostic data, we devised a strict testing environment:
1. **Live USB Environment:** We booted a completely fresh Live USB of
CachyOS (Kernel 6.19.6) to eliminate any potential interference from
installed software, TLP profiles, or custom NetworkManager
configurations.
2. **Aggressive Local Logging:** Because the system freeze physically
locks the PCIe bus and disables the Wi-Fi adapter instantly, using
`netconsole` was impossible (the network drops microseconds before the
freeze).
To overcome this, we wrote an "aggressive logger" script that pipes
`dmesg -w` directly to an independent FAT32 USB drive while issuing a
`sync` command twice a second. This bypassed RAM caching and
physically burned the logs to the drive right up to the moment of the
hard freeze. The script we used was:
```bash
#!/bin/bash
LOG_FILE="/run/media/liveuser/LOGS/kernel_freeze.log"
dmesg -w > "$LOG_FILE" &
while true; do
sync
sleep 0.5
done
```
3. No workarounds (`disable_aspm=n`, `disable_lps_deep=n`) were active
in this test. We manually enabled power saving (`iw dev wlan0 set
power_save on`) and triggered the freeze via typical web browsing.
Here are the precise, unadulterated logs showing the adapter
successfully connecting to the network, sitting idle for about 10
seconds (presumably entering power-saving states), and then suffering
a fatal firmware lockup right before the PCIe bus froze:
```
[ 304.709201] audit: type=1111 ... op=connection-add-activate ...
name="Andrey_5G" ...
[ 305.617785] wlan0: authenticate with 6c:68:a4:1c:97:5b ...
[ 305.660333] wlan0: authenticated
[ 305.661661] wlan0: associate with 6c:68:a4:1c:97:5b (try 1/3)
[ 305.663404] wlan0: associated
[ 305.719997] wlan0: Limiting TX power to 30 (30 - 0) dBm as
advertised by 6c:68:a4:1c:97:5b
... (~10 seconds of idle network time) ...
[ 316.907114] rtw88_8821ce 0000:13:00.0: failed to send h2c command
[ 316.911190] rtw88_8821ce 0000:13:00.0: failed to send h2c command
[ 316.921504] rtw88_8821ce 0000:13:00.0: coex request time out
...
[ 349.630952] rtw88_8821ce 0000:13:00.0: failed to send h2c command
[ 349.635023] rtw88_8821ce 0000:13:00.0: failed to send h2c command
[ 357.811235] rtw88_8821ce 0000:13:00.0: firmware failed to leave lps state
[ 359.797238] rtw88_8821ce 0000:13:00.0: firmware failed to leave lps state
... (repeats indefinitely until hard reset) ...
```
As the logs clearly demonstrate, the adapter authenticates perfectly
but the firmware explicitly fails to leave the LPS state after a brief
idle period, dropping all H2C commands immediately before the
system-wide hard freeze begins.
We will upload the full, unabridged `.log` file to our Bugzilla thread
(Bug 221195) momentarily, but we wanted to provide you with this exact
'smoking gun' trace right away to help identify the root cause.
Please let us know if this information is helpful or if there are any
specific module patches or further tests you would like us to perform
to assist with debugging.
Best regards,
Oleksandr
вт, 10 мар. 2026 г. в 13:01, LB F <goainwo@gmail.com>:
>
> Hi Ping-Ke,
>
> Thank you for the incredibly fast response and assistance!
>
> > Can you dig kernel log (by netconsole or ramoops) if something useful?
> > I'd like to know this is hardware level freeze or kernel can capture something wrong.
>
> I managed to pull a call trace from a historic journald log just
> before the system hung. The kernel gets trapped in an IRQ thread
> inside `rtw_pci_interrupt_threadfn`, calling up into `mac80211`
> `ieee80211_rx_list` before everything freezes. Here is the relevant
> snippet:
>
> ```text
> Call Trace:
> <IRQ>
> ? __alloc_skb+0x23a/0x2a0
> ? __alloc_skb+0x10c/0x2a0
> ? __pfx_irq_thread_fn+0x10/0x10
> [ ... truncated module list ... ]
> Tainted: G W I 6.19.6-2-cachyos #1 PREEMPT(full)
> Hardware name: HP HP Notebook/81F0, BIOS F.50 11/20/2020
> RIP: 0010:ieee80211_rx_list+0x1012/0x1020 [mac80211]
> CPU: 2 UID: 0 PID: 765 Comm: irq/56-rtw88_pc
> rtw_pci_interrupt_threadfn+0x239/0x310 [rtw88_pci]
> ```
>
> It behaves exactly like a PCIe bus deadlock or a hardware fault that
> eventually brings down the CPU handling the IRQ.
>
> > Are these totally needed to workaround the problem? Or disable_aspm is enough?
> > I'd list them in order of power consumption impact:
> > 1. disable_aspm=y
> > 2. disable_lps_deep=y
> > 3. disable WiFi power save
>
> To verify which parameters are strictly necessary, I performed
> isolated testing today. I ensured no other modprobe configs were
> active, rebuilt the initramfs, and manually enforced that
> `wifi.powersave` was active via `iw dev wlan0 set power_save on`
> during all tests (as the OS power management profiles were defaulting
> it to off, which initially masked the issue).
>
> I tested each workaround individually across multiple sleep/wake
> cycles and active usage:
>
> **Test 1 (ASPM Disabled, LPS Deep Enabled):**
> - Kernel parameters: `rtw88_pci disable_aspm=y` (and `rtw88_core
> disable_lps_deep=n`)
> - Result: Stable. No freezes were observed during usage or transitions
> into/out of S3 sleep while power saving was enforced.
>
> **Test 2 (ASPM Enabled, LPS Deep Disabled):**
> - Kernel parameters: `rtw88_core disable_lps_deep=y` (and `rtw88_pci
> disable_aspm=n`)
> - Result: Stable. No freezes were observed under the same forced power
> save conditions.
>
> **Conclusion:** It appears we do not need both workarounds
> simultaneously for this specific hardware. Using only `disable_aspm=y`
> seems to be sufficient to prevent the system freeze. Given your note
> about the power consumption impact ranking, this looks like the
> optimal path forward.
>
> > But what does 'deadlock' mean? As I know NAPI poll is scheduled by ISR,
> > and going to receive packets. The rx_no_aspm workaround is to forcely turn
> > off ASPM during this period.
>
> By "deadlock" I meant a hardware-level bus lockup. It seems the
> physical RTL8821CE chip itself crashes or hangs the system's PCIe bus
> when trying to negotiate waking up from ASPM L1 while simultaneously
> existing in `LPS_DEEP_MODE_LCLK`. The `rx_no_aspm` workaround in NAPI
> helps during active Rx decoding, but the laptop often freezes while
> completely idle, presumably when the AP sends a basic beacon, the chip
> attempts to leave LPS Deep + L1, and the hardware simply gives up and
> halts the system.
>
> > We have not modified RTL8821CE for a long time, so I'd add workaround
> > to specific platform as mentioned above.
>
> Adding a DMI/platform quirk specifically for this laptop to disable
> ASPM would be wonderful and deeply appreciated. I agree it is safer
> than touching the global flags for hardware that is functioning
> correctly out in the wild.
>
> Here is the exact identifying information for my system:
>
> System Vendor: HP
> Product Name: HP Notebook
> SKU Number: P3S95EA#ACB
> Family: 103C_5335KV
> PCI ID: 10ec:c821
> Subsystem ID: 103c:831a
>
> I am completely ready to test any patch or quirk you send my way.
> Thank you so much for your time and helping track this down!
>
> Best regards,
> Oleksandr
^ permalink raw reply
* [PATCH ath-next 0/2] wifi: ath12k: Clean up the WMI Unit Test functionality
From: Jeff Johnson @ 2026-03-10 15:16 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel, Jeff Johnson
Patch 1 updates the core Unit Test functionality to address multiple
existing issues, and patch 2 removes unused DFS Unit Test definitions.
---
Jeff Johnson (2):
wifi: ath12k: Clean up the WMI Unit Test command interface
wifi: ath12k: Remove unused DFS Unit Test definitions
drivers/net/wireless/ath/ath12k/wmi.c | 58 ++++++++++++++++-------------------
drivers/net/wireless/ath/ath12k/wmi.h | 14 ++++++---
2 files changed, 36 insertions(+), 36 deletions(-)
---
base-commit: 9942b3f80f4ebe6852663e0d35ecaf6b7a97c8da
change-id: 20260305-ath12k-unit-test-cleanup-07622698c994
^ permalink raw reply
* [PATCH ath-next 1/2] wifi: ath12k: Clean up the WMI Unit Test command interface
From: Jeff Johnson @ 2026-03-10 15:16 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel, Jeff Johnson
In-Reply-To: <20260310-ath12k-unit-test-cleanup-v1-0-03e3df56f903@oss.qualcomm.com>
Currently, ath12k_wmi_send_unit_test_cmd() provides the interface to
send a Unit Test command to firmware. The payload for the command is
passed in two separate parameters, struct wmi_unit_test_cmd ut_cmd and
u32 *test_args. This interface is strange in that it passes the
ut_cmd structure by value instead of by reference. But even worse,
this presents an interface that is not endian clean since the ut_cmd
structure is defined in little endian format while the test_args array
is defined to be in cpu endian format. Furthermore, the implementation
of this function passes the test_args directly to the firmware, without
performing cpu_to_le32() conversion, and hence this functionality will
not work correctly on big endian platforms.
In order to fix these issues, introduce a new wmi_unit_test_arg
structure which defines all of the parameters needed by the Unit Test
command in a single structure using cpu endian. Update
ath12k_wmi_send_unit_test_cmd() to take a pointer to this structure
and perform all cpu_to_le32() conversions needed while forming the
firmware command. Update the only existing Unit Test function,
ath12k_wmi_simulate_radar(), to properly fill and pass this new
structure to ath12k_wmi_send_unit_test_cmd().
Compile tested only.
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/wmi.c | 58 ++++++++++++++++-------------------
drivers/net/wireless/ath/ath12k/wmi.h | 11 +++++++
2 files changed, 38 insertions(+), 31 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
index b93e33edf369..65a05a9520ff 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.c
+++ b/drivers/net/wireless/ath/ath12k/wmi.c
@@ -10017,50 +10017,46 @@ static int ath12k_connect_pdev_htc_service(struct ath12k_base *ab,
static int
ath12k_wmi_send_unit_test_cmd(struct ath12k *ar,
- struct wmi_unit_test_cmd ut_cmd,
- u32 *test_args)
+ const struct wmi_unit_test_arg *ut)
{
struct ath12k_wmi_pdev *wmi = ar->wmi;
struct wmi_unit_test_cmd *cmd;
+ int buf_len, arg_len;
struct sk_buff *skb;
struct wmi_tlv *tlv;
+ __le32 *ut_cmd_args;
void *ptr;
- u32 *ut_cmd_args;
- int buf_len, arg_len;
int ret;
int i;
- arg_len = sizeof(u32) * le32_to_cpu(ut_cmd.num_args);
- buf_len = sizeof(ut_cmd) + arg_len + TLV_HDR_SIZE;
+ arg_len = sizeof(*ut_cmd_args) * ut->num_args;
+ buf_len = sizeof(*cmd) + arg_len + TLV_HDR_SIZE;
skb = ath12k_wmi_alloc_skb(wmi->wmi_ab, buf_len);
if (!skb)
return -ENOMEM;
- cmd = (struct wmi_unit_test_cmd *)skb->data;
+ ptr = skb->data;
+ cmd = ptr;
cmd->tlv_header = ath12k_wmi_tlv_cmd_hdr(WMI_TAG_UNIT_TEST_CMD,
- sizeof(ut_cmd));
-
- cmd->vdev_id = ut_cmd.vdev_id;
- cmd->module_id = ut_cmd.module_id;
- cmd->num_args = ut_cmd.num_args;
- cmd->diag_token = ut_cmd.diag_token;
-
- ptr = skb->data + sizeof(ut_cmd);
+ sizeof(*cmd));
+ cmd->vdev_id = cpu_to_le32(ut->vdev_id);
+ cmd->module_id = cpu_to_le32(ut->module_id);
+ cmd->num_args = cpu_to_le32(ut->num_args);
+ cmd->diag_token = cpu_to_le32(ut->diag_token);
+ ptr += sizeof(*cmd);
tlv = ptr;
tlv->header = ath12k_wmi_tlv_hdr(WMI_TAG_ARRAY_UINT32, arg_len);
ptr += TLV_HDR_SIZE;
-
ut_cmd_args = ptr;
- for (i = 0; i < le32_to_cpu(ut_cmd.num_args); i++)
- ut_cmd_args[i] = test_args[i];
+ for (i = 0; i < ut->num_args; i++)
+ ut_cmd_args[i] = cpu_to_le32(ut->args[i]);
ath12k_dbg(ar->ab, ATH12K_DBG_WMI,
"WMI unit test : module %d vdev %d n_args %d token %d\n",
- cmd->module_id, cmd->vdev_id, cmd->num_args,
- cmd->diag_token);
+ ut->module_id, ut->vdev_id, ut->num_args, ut->diag_token);
ret = ath12k_wmi_cmd_send(wmi, skb, WMI_UNIT_TEST_CMDID);
@@ -10076,8 +10072,7 @@ ath12k_wmi_send_unit_test_cmd(struct ath12k *ar,
int ath12k_wmi_simulate_radar(struct ath12k *ar)
{
struct ath12k_link_vif *arvif;
- u32 dfs_args[DFS_MAX_TEST_ARGS];
- struct wmi_unit_test_cmd wmi_ut;
+ struct wmi_unit_test_arg wmi_ut = {};
bool arvif_found = false;
list_for_each_entry(arvif, &ar->arvifs, list) {
@@ -10090,22 +10085,23 @@ int ath12k_wmi_simulate_radar(struct ath12k *ar)
if (!arvif_found)
return -EINVAL;
- dfs_args[DFS_TEST_CMDID] = 0;
- dfs_args[DFS_TEST_PDEV_ID] = ar->pdev->pdev_id;
- /* Currently we could pass segment_id(b0 - b1), chirp(b2)
+ wmi_ut.args[DFS_TEST_CMDID] = 0;
+ wmi_ut.args[DFS_TEST_PDEV_ID] = ar->pdev->pdev_id;
+ /*
+ * Currently we could pass segment_id(b0 - b1), chirp(b2)
* freq offset (b3 - b10) to unit test. For simulation
* purpose this can be set to 0 which is valid.
*/
- dfs_args[DFS_TEST_RADAR_PARAM] = 0;
+ wmi_ut.args[DFS_TEST_RADAR_PARAM] = 0;
- wmi_ut.vdev_id = cpu_to_le32(arvif->vdev_id);
- wmi_ut.module_id = cpu_to_le32(DFS_UNIT_TEST_MODULE);
- wmi_ut.num_args = cpu_to_le32(DFS_MAX_TEST_ARGS);
- wmi_ut.diag_token = cpu_to_le32(DFS_UNIT_TEST_TOKEN);
+ wmi_ut.vdev_id = arvif->vdev_id;
+ wmi_ut.module_id = DFS_UNIT_TEST_MODULE;
+ wmi_ut.num_args = DFS_MAX_TEST_ARGS;
+ wmi_ut.diag_token = DFS_UNIT_TEST_TOKEN;
ath12k_dbg(ar->ab, ATH12K_DBG_REG, "Triggering Radar Simulation\n");
- return ath12k_wmi_send_unit_test_cmd(ar, wmi_ut, dfs_args);
+ return ath12k_wmi_send_unit_test_cmd(ar, &wmi_ut);
}
int ath12k_wmi_send_tpc_stats_request(struct ath12k *ar,
diff --git a/drivers/net/wireless/ath/ath12k/wmi.h b/drivers/net/wireless/ath/ath12k/wmi.h
index 0bf0a7941cd3..8d766dd5b304 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.h
+++ b/drivers/net/wireless/ath/ath12k/wmi.h
@@ -4210,6 +4210,17 @@ struct wmi_dfs_unit_test_arg {
u32 radar_param;
};
+/* update if another test command requires more */
+#define WMI_UNIT_TEST_ARGS_MAX DFS_MAX_TEST_ARGS
+
+struct wmi_unit_test_arg {
+ u32 vdev_id;
+ u32 module_id;
+ u32 diag_token;
+ u32 num_args;
+ u32 args[WMI_UNIT_TEST_ARGS_MAX];
+};
+
struct wmi_unit_test_cmd {
__le32 tlv_header;
__le32 vdev_id;
--
2.43.0
^ permalink raw reply related
* [PATCH ath-next 2/2] wifi: ath12k: Remove unused DFS Unit Test definitions
From: Jeff Johnson @ 2026-03-10 15:16 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel, Jeff Johnson
In-Reply-To: <20260310-ath12k-unit-test-cleanup-v1-0-03e3df56f903@oss.qualcomm.com>
The following are unused, so remove them:
struct wmi_dfs_unit_test_arg
macro DFS_PHYERR_UNIT_TEST_CMD
Compile tested only.
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/wmi.h | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/wmi.h b/drivers/net/wireless/ath/ath12k/wmi.h
index 8d766dd5b304..5ba9b7d3a888 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.h
+++ b/drivers/net/wireless/ath/ath12k/wmi.h
@@ -4193,7 +4193,6 @@ struct wmi_addba_clear_resp_cmd {
struct ath12k_wmi_mac_addr_params peer_macaddr;
} __packed;
-#define DFS_PHYERR_UNIT_TEST_CMD 0
#define DFS_UNIT_TEST_MODULE 0x2b
#define DFS_UNIT_TEST_TOKEN 0xAA
@@ -4204,12 +4203,6 @@ enum dfs_test_args_idx {
DFS_MAX_TEST_ARGS,
};
-struct wmi_dfs_unit_test_arg {
- u32 cmd_id;
- u32 pdev_id;
- u32 radar_param;
-};
-
/* update if another test command requires more */
#define WMI_UNIT_TEST_ARGS_MAX DFS_MAX_TEST_ARGS
--
2.43.0
^ permalink raw reply related
* Re: (subset) [PATCH v2 00/18] wifi: drop redundant USB device references
From: Jeff Johnson @ 2026-03-10 15:31 UTC (permalink / raw)
To: linux-wireless, Johan Hovold
Cc: Jeff Johnson, Toke Høiland-Jørgensen, Brian Norris,
Francesco Dolcini, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Jakub Kicinski, Stanislaw Gruszka,
Hin-Tak Leung, Jes Sorensen, Ping-Ke Shih, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Matthias Brugger,
AngeloGioacchino Del Regno, Greg Kroah-Hartman, libertas-dev,
linux-kernel
In-Reply-To: <20260306085144.12064-1-johan@kernel.org>
On Fri, 06 Mar 2026 09:51:26 +0100, Johan Hovold wrote:
> Driver core holds a reference to the USB interface and its parent USB
> device while the interface is bound to a driver and there is no need to
> take additional references unless the structures are needed after
> disconnect.
>
> Drop redundant device references to reduce cargo culting, make it easier
> to spot drivers where an extra reference is needed, and reduce the risk
> of memory leaks when drivers fail to release them.
>
> [...]
Applied, thanks!
[01/18] wifi: ath6kl: drop redundant device reference
commit: 86581adf05f526f53b90ebcbbc2fd4d9f9fd4c96
[02/18] wifi: ath6kl: rename disconnect callback
commit: 0bc013d68a5d1943728d110d759c6587c2b81913
[03/18] wifi: ath9k: drop redundant device reference
commit: 2ddbec82e1650d57ea0f63d284b5da01d2f21293
[04/18] wifi: ath10k: drop redundant device reference
commit: c880c0794076f04b0058dd5cbc1f94c33d7bff44
[05/18] wifi: ath10k: rename disconnect callback
commit: fcc3555fce3c35333891e904c3592375d5e63cf4
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: Use .mbn firmware for AHB devices
From: Jeff Johnson @ 2026-03-10 15:31 UTC (permalink / raw)
To: ath12k, Aaradhana Sahu; +Cc: linux-wireless
In-Reply-To: <20260306032252.2237722-1-aaradhana.sahu@oss.qualcomm.com>
On Fri, 06 Mar 2026 08:52:52 +0530, Aaradhana Sahu wrote:
> Currently ath12k AHB devices request firmware in .mdt/.bxx split
> format. AHB firmware is transitioning from the split format to a
> single .mbn file.
>
> Update ath12k to request q6_fw.mbn and iu_fw.mbn instead of q6_fw.mdt
> iu_fw.mdt respectively.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: Use .mbn firmware for AHB devices
commit: 27401c9b143278eb9fa7d46f97ab063d65e5afd5
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 05/10 net-next v2] drivers: net: drop ipv6_stub usage and use direct function calls
From: Fernando Fernandez Mancera @ 2026-03-10 15:34 UTC (permalink / raw)
To: netdev
Cc: rbm, Fernando Fernandez Mancera, Jason Gunthorpe, Leon Romanovsky,
Zhu Yanjun, Saeed Mahameed, Tariq Toukan, Mark Bloch, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Boris Pismenny, Ido Schimmel, Petr Machata, Simon Horman,
Edward Cree, Pablo Neira Ayuso, Harald Welte, Antonio Quartulli,
Sabrina Dubroca, Oliver Neukum, David Ahern, Jason A. Donenfeld,
Stanislav Yakovlev, Nikolay Aleksandrov, Parav Pandit,
Edward Srouji, Vlad Dumitrescu, Kees Cook, Jianbo Liu,
Gal Pressman, Guillaume Nault, Cosmin Ratiu, Carolina Jubran,
Alexandre Cassen, Stanislav Fomichev,
open list:INFINIBAND SUBSYSTEM, open list,
open list:NETRONOME ETHERNET DRIVERS,
open list:SFC NETWORK DRIVER,
open list:GTP (GPRS Tunneling Protocol),
open list:USB CDC ETHERNET DRIVER,
open list:WIREGUARD SECURE NETWORK TUNNEL,
open list:INTEL PRO/WIRELESS 2100, 2200BG, 2915ABG NETWOR...,
open list:ETHERNET BRIDGE
In-Reply-To: <20260310153506.5181-1-fmancera@suse.de>
As IPv6 is built-in only, the ipv6_stub infrastructure is no longer
necessary.
Convert all drivers currently utilizing ipv6_stub to make direct
function calls. The fallback functions introduced previously will
prevent linkage errors when CONFIG_IPV6 is disabled.
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
v2: no changes
---
drivers/infiniband/core/addr.c | 3 +--
drivers/infiniband/sw/rxe/rxe_net.c | 6 +++---
.../ethernet/mellanox/mlx5/core/en/rep/neigh.c | 12 ++++++++----
.../net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 3 +--
.../mellanox/mlx5/core/en/tc_tun_encap.c | 2 +-
.../mellanox/mlx5/core/en_accel/ipsec.c | 1 -
.../net/ethernet/mellanox/mlx5/core/en_rep.c | 1 -
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 1 -
.../ethernet/mellanox/mlxsw/spectrum_router.c | 9 +++++----
.../net/ethernet/mellanox/mlxsw/spectrum_span.c | 3 ++-
.../net/ethernet/netronome/nfp/flower/action.c | 2 +-
.../ethernet/netronome/nfp/flower/tunnel_conf.c | 9 ++++-----
drivers/net/ethernet/sfc/tc_counters.c | 2 +-
drivers/net/ethernet/sfc/tc_encap_actions.c | 5 ++---
drivers/net/geneve.c | 1 -
drivers/net/gtp.c | 2 +-
drivers/net/ovpn/peer.c | 3 +--
drivers/net/ovpn/udp.c | 3 +--
drivers/net/usb/cdc_mbim.c | 17 +++++++++--------
drivers/net/vrf.c | 3 ++-
drivers/net/vxlan/vxlan_core.c | 11 +++++------
drivers/net/vxlan/vxlan_multicast.c | 6 ++----
drivers/net/wireguard/socket.c | 3 +--
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
net/bridge/br_arp_nd_proxy.c | 3 +--
25 files changed, 53 insertions(+), 60 deletions(-)
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index 866746695712..48d4b06384ec 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -41,7 +41,6 @@
#include <net/neighbour.h>
#include <net/route.h>
#include <net/netevent.h>
-#include <net/ipv6_stubs.h>
#include <net/ip6_route.h>
#include <rdma/ib_addr.h>
#include <rdma/ib_cache.h>
@@ -411,7 +410,7 @@ static int addr6_resolve(struct sockaddr *src_sock,
fl6.saddr = src_in->sin6_addr;
fl6.flowi6_oif = addr->bound_dev_if;
- dst = ipv6_stub->ipv6_dst_lookup_flow(addr->net, NULL, &fl6, NULL);
+ dst = ip6_dst_lookup_flow(addr->net, NULL, &fl6, NULL);
if (IS_ERR(dst))
return PTR_ERR(dst);
diff --git a/drivers/infiniband/sw/rxe/rxe_net.c b/drivers/infiniband/sw/rxe/rxe_net.c
index 0bd0902b11f7..cbc646a30003 100644
--- a/drivers/infiniband/sw/rxe/rxe_net.c
+++ b/drivers/infiniband/sw/rxe/rxe_net.c
@@ -138,9 +138,9 @@ static struct dst_entry *rxe_find_route6(struct rxe_qp *qp,
memcpy(&fl6.daddr, daddr, sizeof(*daddr));
fl6.flowi6_proto = IPPROTO_UDP;
- ndst = ipv6_stub->ipv6_dst_lookup_flow(sock_net(recv_sockets.sk6->sk),
- recv_sockets.sk6->sk, &fl6,
- NULL);
+ ndst = ip6_dst_lookup_flow(sock_net(recv_sockets.sk6->sk),
+ recv_sockets.sk6->sk, &fl6,
+ NULL);
if (IS_ERR(ndst)) {
rxe_dbg_qp(qp, "no route to %pI6\n", daddr);
return NULL;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/rep/neigh.c b/drivers/net/ethernet/mellanox/mlx5/core/en/rep/neigh.c
index d220b045b331..56930bad94eb 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/rep/neigh.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/rep/neigh.c
@@ -10,6 +10,7 @@
#include <linux/notifier.h>
#include <net/netevent.h>
#include <net/arp.h>
+#include <net/ndisc.h>
#include "neigh.h"
#include "tc.h"
#include "en_rep.h"
@@ -18,8 +19,10 @@
static unsigned long mlx5e_rep_ipv6_interval(void)
{
- if (IS_ENABLED(CONFIG_IPV6) && ipv6_stub->nd_tbl)
- return NEIGH_VAR(&ipv6_stub->nd_tbl->parms, DELAY_PROBE_TIME);
+ struct neigh_table *tbl = ipv6_get_nd_tbl();
+
+ if (IS_ENABLED(CONFIG_IPV6) && ipv6_mod_enabled())
+ return NEIGH_VAR(&tbl->parms, DELAY_PROBE_TIME);
return ~0UL;
}
@@ -217,7 +220,7 @@ static int mlx5e_rep_netevent_event(struct notifier_block *nb,
case NETEVENT_NEIGH_UPDATE:
n = ptr;
#if IS_ENABLED(CONFIG_IPV6)
- if (n->tbl != ipv6_stub->nd_tbl && n->tbl != &arp_tbl)
+ if (n->tbl != ipv6_get_nd_tbl() && n->tbl != &arp_tbl)
#else
if (n->tbl != &arp_tbl)
#endif
@@ -238,7 +241,8 @@ static int mlx5e_rep_netevent_event(struct notifier_block *nb,
* done per device delay prob time parameter.
*/
#if IS_ENABLED(CONFIG_IPV6)
- if (!p->dev || (p->tbl != ipv6_stub->nd_tbl && p->tbl != &arp_tbl))
+ if (!p->dev ||
+ (p->tbl != ipv6_get_nd_tbl() && p->tbl != &arp_tbl))
#else
if (!p->dev || p->tbl != &arp_tbl)
#endif
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
index a14f216048cd..de74dbfe7b20 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
@@ -453,8 +453,7 @@ static int mlx5e_route_lookup_ipv6_get(struct mlx5e_priv *priv,
if (tunnel && tunnel->get_remote_ifindex)
attr->fl.fl6.flowi6_oif = tunnel->get_remote_ifindex(dev);
- dst = ipv6_stub->ipv6_dst_lookup_flow(dev_net(dev), NULL, &attr->fl.fl6,
- NULL);
+ dst = ip6_dst_lookup_flow(dev_net(dev), NULL, &attr->fl.fl6, NULL);
if (IS_ERR(dst))
return PTR_ERR(dst);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c
index bfd401bee9e8..ce2a27124642 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c
@@ -402,7 +402,7 @@ void mlx5e_tc_update_neigh_used_value(struct mlx5e_neigh_hash_entry *nhe)
tbl = &arp_tbl;
#if IS_ENABLED(CONFIG_IPV6)
else if (m_neigh->family == AF_INET6)
- tbl = ipv6_stub->nd_tbl;
+ tbl = ipv6_get_nd_tbl();
#endif
else
return;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
index 64e13747084e..a52e12c3c95a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
@@ -36,7 +36,6 @@
#include <linux/inetdevice.h>
#include <linux/netdevice.h>
#include <net/netevent.h>
-#include <net/ipv6_stubs.h>
#include "en.h"
#include "eswitch.h"
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
index 1db4ecb2356f..5ec5cae8d229 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -38,7 +38,6 @@
#include <net/pkt_cls.h>
#include <net/act_api.h>
#include <net/devlink.h>
-#include <net/ipv6_stubs.h>
#include "eswitch.h"
#include "en.h"
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 1434b65d4746..4e4ee1d520ce 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -40,7 +40,6 @@
#include <linux/refcount.h>
#include <linux/completion.h>
#include <net/arp.h>
-#include <net/ipv6_stubs.h>
#include <net/bareudp.h>
#include <net/bonding.h>
#include <net/dst_metadata.h>
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 7bd87d0547d8..8531216f6389 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -2458,7 +2458,7 @@ static void mlxsw_sp_router_neigh_ent_ipv6_process(struct mlxsw_sp *mlxsw_sp,
}
dev = mlxsw_sp_rif_dev(mlxsw_sp->router->rifs[rif]);
- n = neigh_lookup(&nd_tbl, &dip, dev);
+ n = neigh_lookup(ipv6_get_nd_tbl(), &dip, dev);
if (!n)
return;
@@ -3022,7 +3022,8 @@ static int mlxsw_sp_neigh_rif_made_sync(struct mlxsw_sp *mlxsw_sp,
goto err_arp;
#if IS_ENABLED(CONFIG_IPV6)
- neigh_for_each(&nd_tbl, mlxsw_sp_neigh_rif_made_sync_each, &rms);
+ neigh_for_each(ipv6_get_nd_tbl(),
+ mlxsw_sp_neigh_rif_made_sync_each, &rms);
#endif
if (rms.err)
goto err_nd;
@@ -5124,7 +5125,7 @@ mlxsw_sp_nexthop_obj_init(struct mlxsw_sp *mlxsw_sp,
case AF_INET6:
memcpy(&nh->gw_addr, &nh_obj->ipv6, sizeof(nh_obj->ipv6));
#if IS_ENABLED(CONFIG_IPV6)
- nh->neigh_tbl = &nd_tbl;
+ nh->neigh_tbl = ipv6_get_nd_tbl();
#endif
break;
}
@@ -6980,7 +6981,7 @@ static int mlxsw_sp_nexthop6_init(struct mlxsw_sp *mlxsw_sp,
nh->nh_weight = rt->fib6_nh->fib_nh_weight;
memcpy(&nh->gw_addr, &rt->fib6_nh->fib_nh_gw6, sizeof(nh->gw_addr));
#if IS_ENABLED(CONFIG_IPV6)
- nh->neigh_tbl = &nd_tbl;
+ nh->neigh_tbl = ipv6_get_nd_tbl();
#endif
err = mlxsw_sp_nexthop_counter_enable(mlxsw_sp, nh);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index ae63d549b542..f05ccf3db876 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -576,7 +576,8 @@ mlxsw_sp_span_entry_gretap6_parms(struct mlxsw_sp *mlxsw_sp,
l3edev = mlxsw_sp_span_gretap6_route(to_dev, &saddr.addr6, &gw.addr6);
return mlxsw_sp_span_entry_tunnel_parms_common(l3edev, saddr, daddr, gw,
tparm.hop_limit,
- &nd_tbl, sparmsp);
+ ipv6_get_nd_tbl(),
+ sparmsp);
}
static int
diff --git a/drivers/net/ethernet/netronome/nfp/flower/action.c b/drivers/net/ethernet/netronome/nfp/flower/action.c
index aca2a7417af3..ae2f8b31adfb 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/action.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/action.c
@@ -470,7 +470,7 @@ nfp_fl_set_tun(struct nfp_app *app, struct nfp_fl_set_tun *set_tun,
flow.daddr = ip_tun->key.u.ipv6.dst;
flow.flowi4_proto = IPPROTO_UDP;
- dst = ipv6_stub->ipv6_dst_lookup_flow(net, NULL, &flow, NULL);
+ dst = ip6_dst_lookup_flow(net, NULL, &flow, NULL);
if (!IS_ERR(dst)) {
set_tun->ttl = ip6_dst_hoplimit(dst);
dst_release(dst);
diff --git a/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c b/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
index 0cef0e2b85d0..053265e135f6 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c
@@ -277,7 +277,7 @@ void nfp_tunnel_keep_alive_v6(struct nfp_app *app, struct sk_buff *skb)
if (!netdev)
continue;
- n = neigh_lookup(&nd_tbl, ipv6_add, netdev);
+ n = neigh_lookup(ipv6_get_nd_tbl(), ipv6_add, netdev);
if (!n)
continue;
@@ -650,7 +650,7 @@ static void nfp_tun_neigh_update(struct work_struct *work)
flow6.daddr = *(struct in6_addr *)n->primary_key;
if (!neigh_invalid) {
struct dst_entry *dst;
- /* Use ipv6_dst_lookup_flow to populate flow6->saddr
+ /* Use ip6_dst_lookup_flow to populate flow6->saddr
* and other fields. This information is only needed
* for new entries, lookup can be skipped when an entry
* gets invalidated - as only the daddr is needed for
@@ -730,7 +730,7 @@ nfp_tun_neigh_event_handler(struct notifier_block *nb, unsigned long event,
return NOTIFY_DONE;
}
#if IS_ENABLED(CONFIG_IPV6)
- if (n->tbl != ipv6_stub->nd_tbl && n->tbl != &arp_tbl)
+ if (n->tbl != ipv6_get_nd_tbl() && n->tbl != &arp_tbl)
#else
if (n->tbl != &arp_tbl)
#endif
@@ -815,8 +815,7 @@ void nfp_tunnel_request_route_v6(struct nfp_app *app, struct sk_buff *skb)
flow.flowi6_proto = IPPROTO_UDP;
#if IS_ENABLED(CONFIG_INET) && IS_ENABLED(CONFIG_IPV6)
- dst = ipv6_stub->ipv6_dst_lookup_flow(dev_net(netdev), NULL, &flow,
- NULL);
+ dst = ip6_dst_lookup_flow(dev_net(netdev), NULL, &flow, NULL);
if (IS_ERR(dst))
goto fail_rcu_unlock;
#else
diff --git a/drivers/net/ethernet/sfc/tc_counters.c b/drivers/net/ethernet/sfc/tc_counters.c
index d168282f30bf..d8a5f9fd1007 100644
--- a/drivers/net/ethernet/sfc/tc_counters.c
+++ b/drivers/net/ethernet/sfc/tc_counters.c
@@ -112,7 +112,7 @@ static void efx_tc_counter_work(struct work_struct *work)
encap->neigh->egdev);
else
#if IS_ENABLED(CONFIG_IPV6)
- n = neigh_lookup(ipv6_stub->nd_tbl,
+ n = neigh_lookup(ipv6_get_nd_tbl(),
&encap->neigh->dst_ip6,
encap->neigh->egdev);
#else
diff --git a/drivers/net/ethernet/sfc/tc_encap_actions.c b/drivers/net/ethernet/sfc/tc_encap_actions.c
index da35705cc5e1..63d8f794b869 100644
--- a/drivers/net/ethernet/sfc/tc_encap_actions.c
+++ b/drivers/net/ethernet/sfc/tc_encap_actions.c
@@ -149,8 +149,7 @@ static int efx_bind_neigh(struct efx_nic *efx,
#if IS_ENABLED(CONFIG_IPV6)
struct dst_entry *dst;
- dst = ipv6_stub->ipv6_dst_lookup_flow(net, NULL, &flow6,
- NULL);
+ dst = ip6_dst_lookup_flow(net, NULL, &flow6, NULL);
rc = PTR_ERR_OR_ZERO(dst);
if (rc) {
NL_SET_ERR_MSG_MOD(extack, "Failed to lookup route for IPv6 encap");
@@ -531,7 +530,7 @@ static int efx_neigh_event(struct efx_nic *efx, struct neighbour *n)
if (n->tbl == &arp_tbl) {
keysize = sizeof(keys.dst_ip);
#if IS_ENABLED(CONFIG_IPV6)
- } else if (n->tbl == ipv6_stub->nd_tbl) {
+ } else if (n->tbl == ipv6_get_nd_tbl()) {
ipv6 = true;
keysize = sizeof(keys.dst_ip6);
#endif
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 01cdd06102e0..c6563367d382 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -12,7 +12,6 @@
#include <linux/module.h>
#include <linux/etherdevice.h>
#include <linux/hash.h>
-#include <net/ipv6_stubs.h>
#include <net/dst_metadata.h>
#include <net/gro_cells.h>
#include <net/rtnetlink.h>
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index e8949f556209..70b9e58b9b78 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -374,7 +374,7 @@ static struct rt6_info *ip6_route_output_gtp(struct net *net,
fl6->saddr = *saddr;
fl6->flowi6_proto = sk->sk_protocol;
- dst = ipv6_stub->ipv6_dst_lookup_flow(net, sk, fl6, NULL);
+ dst = ip6_dst_lookup_flow(net, sk, fl6, NULL);
if (IS_ERR(dst))
return ERR_PTR(-ENETUNREACH);
diff --git a/drivers/net/ovpn/peer.c b/drivers/net/ovpn/peer.c
index 3716a1d82801..6dd11c71204b 100644
--- a/drivers/net/ovpn/peer.c
+++ b/drivers/net/ovpn/peer.c
@@ -821,8 +821,7 @@ static struct in6_addr ovpn_nexthop_from_rt6(struct ovpn_priv *ovpn,
.daddr = dest,
};
- entry = ipv6_stub->ipv6_dst_lookup_flow(dev_net(ovpn->dev), NULL, &fl,
- NULL);
+ entry = ip6_dst_lookup_flow(dev_net(ovpn->dev), NULL, &fl, NULL);
if (IS_ERR(entry)) {
net_dbg_ratelimited("%s: no route to host %pI6c\n",
netdev_name(ovpn->dev), &dest);
diff --git a/drivers/net/ovpn/udp.c b/drivers/net/ovpn/udp.c
index 272b535ecaad..059e896b4a2f 100644
--- a/drivers/net/ovpn/udp.c
+++ b/drivers/net/ovpn/udp.c
@@ -14,7 +14,6 @@
#include <net/addrconf.h>
#include <net/dst_cache.h>
#include <net/route.h>
-#include <net/ipv6_stubs.h>
#include <net/transp_v6.h>
#include <net/udp.h>
#include <net/udp_tunnel.h>
@@ -251,7 +250,7 @@ static int ovpn_udp6_output(struct ovpn_peer *peer, struct ovpn_bind *bind,
dst_cache_reset(cache);
}
- dst = ipv6_stub->ipv6_dst_lookup_flow(sock_net(sk), sk, &fl, NULL);
+ dst = ip6_dst_lookup_flow(sock_net(sk), sk, &fl, NULL);
if (IS_ERR(dst)) {
ret = PTR_ERR(dst);
net_dbg_ratelimited("%s: no route to host %pISpc: %d\n",
diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index dbf01210b0e7..877fb0ed7d3d 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -20,7 +20,6 @@
#include <linux/usb/cdc_ncm.h>
#include <net/ipv6.h>
#include <net/addrconf.h>
-#include <net/ipv6_stubs.h>
#include <net/ndisc.h>
/* alternative VLAN for IP session 0 if not untagged */
@@ -302,6 +301,7 @@ static struct sk_buff *cdc_mbim_tx_fixup(struct usbnet *dev, struct sk_buff *skb
return NULL;
}
+#if IS_ENABLED(CONFIG_IPV6)
/* Some devices are known to send Neighbor Solicitation messages and
* require Neighbor Advertisement replies. The IPv6 core will not
* respond since IFF_NOARP is set, so we must handle them ourselves.
@@ -342,12 +342,11 @@ static void do_neigh_solicit(struct usbnet *dev, u8 *buf, u16 tci)
is_router = !!READ_ONCE(in6_dev->cnf.forwarding);
in6_dev_put(in6_dev);
- /* ipv6_stub != NULL if in6_dev_get returned an inet6_dev */
- ipv6_stub->ndisc_send_na(netdev, &iph->saddr, &msg->target,
- is_router /* router */,
- true /* solicited */,
- false /* override */,
- true /* inc_opt */);
+ ndisc_send_na(netdev, &iph->saddr, &msg->target,
+ is_router /* router */,
+ true /* solicited */,
+ false /* override */,
+ true /* inc_opt */);
out:
dev_put(netdev);
}
@@ -362,7 +361,7 @@ static bool is_neigh_solicit(u8 *buf, size_t len)
msg->icmph.icmp6_code == 0 &&
msg->icmph.icmp6_type == NDISC_NEIGHBOUR_SOLICITATION);
}
-
+#endif /* IPV6 */
static struct sk_buff *cdc_mbim_process_dgram(struct usbnet *dev, u8 *buf, size_t len, u16 tci)
{
@@ -378,8 +377,10 @@ static struct sk_buff *cdc_mbim_process_dgram(struct usbnet *dev, u8 *buf, size_
proto = htons(ETH_P_IP);
break;
case 0x60:
+#if IS_ENABLED(CONFIG_IPV6)
if (is_neigh_solicit(buf, len))
do_neigh_solicit(dev, buf, tci);
+#endif
proto = htons(ETH_P_IPV6);
break;
default:
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 8c009bcaa8e7..68edb47cc4eb 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -616,7 +616,8 @@ static int vrf_finish_output6(struct net *net, struct sock *sk,
nexthop = rt6_nexthop(dst_rt6_info(dst), &ipv6_hdr(skb)->daddr);
neigh = __ipv6_neigh_lookup_noref(dst->dev, nexthop);
if (unlikely(!neigh))
- neigh = __neigh_create(&nd_tbl, nexthop, dst->dev, false);
+ neigh = __neigh_create(ipv6_get_nd_tbl(), nexthop,
+ dst->dev, false);
if (!IS_ERR(neigh)) {
sock_confirm_neigh(skb, neigh);
ret = neigh_output(neigh, skb, false);
diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
index 17c941aac32d..4ab94dfe0d12 100644
--- a/drivers/net/vxlan/vxlan_core.c
+++ b/drivers/net/vxlan/vxlan_core.c
@@ -19,7 +19,6 @@
#include <net/arp.h>
#include <net/ndisc.h>
#include <net/gro.h>
-#include <net/ipv6_stubs.h>
#include <net/ip.h>
#include <net/icmp.h>
#include <net/rtnetlink.h>
@@ -2045,7 +2044,7 @@ static int neigh_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni)
ipv6_addr_is_multicast(&msg->target))
goto out;
- n = neigh_lookup(ipv6_stub->nd_tbl, &msg->target, dev);
+ n = neigh_lookup(ipv6_get_nd_tbl(), &msg->target, dev);
if (n) {
struct vxlan_rdst *rdst = NULL;
@@ -2130,15 +2129,15 @@ static bool route_shortcircuit(struct net_device *dev, struct sk_buff *skb)
{
struct ipv6hdr *pip6;
- /* check if nd_tbl is not initiliazed due to
- * ipv6.disable=1 set during boot
+ /* check if ipv6.disable=1 set during boot was set
+ * during booting so nd_tbl is not initialized
*/
- if (!ipv6_stub->nd_tbl)
+ if (!ipv6_mod_enabled())
return false;
if (!pskb_may_pull(skb, sizeof(struct ipv6hdr)))
return false;
pip6 = ipv6_hdr(skb);
- n = neigh_lookup(ipv6_stub->nd_tbl, &pip6->daddr, dev);
+ n = neigh_lookup(ipv6_get_nd_tbl(), &pip6->daddr, dev);
if (!n && (vxlan->cfg.flags & VXLAN_F_L3MISS)) {
union vxlan_addr ipa = {
.sin6.sin6_addr = pip6->daddr,
diff --git a/drivers/net/vxlan/vxlan_multicast.c b/drivers/net/vxlan/vxlan_multicast.c
index a7f2d67dc61b..b0e80bca855c 100644
--- a/drivers/net/vxlan/vxlan_multicast.c
+++ b/drivers/net/vxlan/vxlan_multicast.c
@@ -39,8 +39,7 @@ int vxlan_igmp_join(struct vxlan_dev *vxlan, union vxlan_addr *rip,
sk = sock6->sock->sk;
lock_sock(sk);
- ret = ipv6_stub->ipv6_sock_mc_join(sk, ifindex,
- &ip->sin6.sin6_addr);
+ ret = ipv6_sock_mc_join(sk, ifindex, &ip->sin6.sin6_addr);
release_sock(sk);
#endif
}
@@ -73,8 +72,7 @@ int vxlan_igmp_leave(struct vxlan_dev *vxlan, union vxlan_addr *rip,
sk = sock6->sock->sk;
lock_sock(sk);
- ret = ipv6_stub->ipv6_sock_mc_drop(sk, ifindex,
- &ip->sin6.sin6_addr);
+ ret = ipv6_sock_mc_drop(sk, ifindex, &ip->sin6.sin6_addr);
release_sock(sk);
#endif
}
diff --git a/drivers/net/wireguard/socket.c b/drivers/net/wireguard/socket.c
index 253488f8c00f..c362c78d908e 100644
--- a/drivers/net/wireguard/socket.c
+++ b/drivers/net/wireguard/socket.c
@@ -136,8 +136,7 @@ static int send6(struct wg_device *wg, struct sk_buff *skb,
if (cache)
dst_cache_reset(cache);
}
- dst = ipv6_stub->ipv6_dst_lookup_flow(sock_net(sock), sock, &fl,
- NULL);
+ dst = ip6_dst_lookup_flow(sock_net(sock), sock, &fl, NULL);
if (IS_ERR(dst)) {
ret = PTR_ERR(dst);
net_dbg_ratelimited("%s: No route to %pISpfsc, error %d\n",
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index 248a051da52d..c11428485dcc 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -4838,7 +4838,7 @@ static int ipw2100_system_config(struct ipw2100_priv *priv, int batch_mode)
/* If IPv6 is configured in the kernel then we don't want to filter out all
* of the multicast packets as IPv6 needs some. */
-#if !defined(CONFIG_IPV6) && !defined(CONFIG_IPV6_MODULE)
+#if !defined(CONFIG_IPV6)
cmd.host_command = ADD_MULTICAST;
cmd.host_command_sequence = 0;
cmd.host_command_length = 0;
diff --git a/net/bridge/br_arp_nd_proxy.c b/net/bridge/br_arp_nd_proxy.c
index 1e2b51769eec..494bf69a3017 100644
--- a/net/bridge/br_arp_nd_proxy.c
+++ b/net/bridge/br_arp_nd_proxy.c
@@ -17,7 +17,6 @@
#include <linux/if_vlan.h>
#include <linux/inetdevice.h>
#include <net/addrconf.h>
-#include <net/ipv6_stubs.h>
#if IS_ENABLED(CONFIG_IPV6)
#include <net/ip6_checksum.h>
#endif
@@ -455,7 +454,7 @@ void br_do_suppress_nd(struct sk_buff *skb, struct net_bridge *br,
return;
}
- n = neigh_lookup(ipv6_stub->nd_tbl, &msg->target, vlandev);
+ n = neigh_lookup(ipv6_get_nd_tbl(), &msg->target, vlandev);
if (n) {
struct net_bridge_fdb_entry *f;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 01/61] Coccinelle: Prefer IS_ERR_OR_NULL over manual NULL check
From: Markus Elfring @ 2026-03-10 15:41 UTC (permalink / raw)
To: Philipp Hahn, cocci, Julia Lawall
Cc: amd-gfx, apparmor, bpf, ceph-devel, dm-devel, dri-devel, gfs2,
intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, nicolas.palix, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs
In-Reply-To: <20260310-b4-is_err_or_null-v1-1-bd63b656022d@avm.de>
> Find and convert uses of IS_ERR() plus NULL check to IS_ERR_OR_NULL().
…
Can this information trigger any more consequences on corresponding summary phrases?
…
> +++ b/scripts/coccinelle/api/is_err_or_null.cocci
> @@ -0,0 +1,125 @@
…
> +virtual patch
> +virtual report
> +virtual org
How will interests evolve further for the support of the operation mode “context”?
> +@p1 depends on patch@
> +expression E;
> +@@
> +(
> +- E != NULL && !IS_ERR(E)
> ++ !IS_ERR_OR_NULL(E)
> +|
> +- E == NULL || IS_ERR(E)
> ++ IS_ERR_OR_NULL(E)
> +|
> +- !IS_ERR(E) && E != NULL
> ++ !IS_ERR_OR_NULL(E)
> +|
> +- IS_ERR(E) || E == NULL
> ++ IS_ERR_OR_NULL(E)
> +)
Did you eventually check probabilities for the occurrence of mentioned case distinctions?
> +@p2 depends on patch@
…
I suggest to reconsider “side effects” according to the splitting of these SmPL rules
once more.
…
> +@r2 depends on report || org@
> +identifier I;
> +expression E;
> +position p;
> +@@
> +(
> +* (I = E) != NULL && ... && !IS_ERR@p(I)
> +|
> +* (I = E) == NULL || ... || IS_ERR@p(I)
> +)
I doubt that the usage of SmPL asterisks fits to these two operation modes.
…
> +@p5 depends on patch disable unlikely @
> +expression E;
> +@@
> +-\( likely \| unlikely \)(
> +(
> + IS_ERR_OR_NULL(E)
> +|
> + !IS_ERR_OR_NULL(E)
> +)
> +-)
* Would it be nicer to move such SmPL code to the end of the patch rule listing?
* Can this source code search pattern matter also for further operation modes?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] wifi: wlcore: ensure skb headroom before skb_push
From: Peter Åstrand @ 2026-03-10 15:52 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-wireless
In-Reply-To: <1768df30-cac9-4c55-a8bf-1d927d59029c@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]
On Wed, 25 Feb 2026, Guenter Roeck wrote:
> Hi,
>
> On Wed, Dec 03, 2025 at 08:57:08AM +0100, Peter Åstrand wrote:
> >
> > This avoids occasional skb_under_panic Oops from wl1271_tx_work. In this case, headroom is
> > less than needed (typically 110 - 94 = 16 bytes).
> >
> > Signed-off-by: Peter Astrand <astrand@lysator.liu.se>
> > ---
> > drivers/net/wireless/ti/wlcore/tx.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/net/wireless/ti/wlcore/tx.c b/drivers/net/wireless/ti/wlcore/tx.c
> > index f76087be2f75..6241866d39df 100644
> > --- a/drivers/net/wireless/ti/wlcore/tx.c
> > +++ b/drivers/net/wireless/ti/wlcore/tx.c
> > @@ -207,6 +207,11 @@ static int wl1271_tx_allocate(struct wl1271 *wl, struct wl12xx_vif *wlvif,
> > total_blocks = wlcore_hw_calc_tx_blocks(wl, total_len, spare_blocks);
> >
> > if (total_blocks <= wl->tx_blocks_available) {
> > + if (skb_headroom(skb) < (total_len - skb->len) &&
> > + pskb_expand_head(skb, (total_len - skb->len), 0, GFP_ATOMIC)) {
> > + wl1271_free_tx_id(wl, id);
> > + return -EAGAIN;
> > + }
>
> An experimental AI code review agent provided the following feedback:
>
> If pskb_expand_head() fails, the code returns -EAGAIN. However, in
> wlcore_tx_work_locked(), a return value of -EAGAIN from
> wl1271_prepare_tx_frame() is interpreted as the aggregation buffer being full.
> This causes the code to flush the buffer, put the skb back at the head of the
> queue, and immediately retry the same skb in a tight while loop.
>
> Because wlcore_tx_work_locked() holds wl->mutex, and the retry happens
> immediately with GFP_ATOMIC, will this result in an infinite loop and a CPU
> soft lockup? Should this return -ENOMEM instead, so the packet is dropped and
> the loop terminates?
>
> I don't understand the code well enough to understand if the AI agent has a
> point or not. Please take a look and let me know if this is a real problem.
From my perspective, this makes sense. We have never seen any CPU soft
lockup, but perhaps pskb_expand_head() never fails on our systems. ath12k
also returns -ENOMEM when pskb_expand_head() fails.
Can you submit a patch?
Best regards,
Peter
^ permalink raw reply
* [PATCH] wifi: mac80211: fix WARN_ON_ONCE in ieee80211_tdls_oper
From: Deepanshu Kartikey @ 2026-03-10 16:00 UTC (permalink / raw)
To: johannes
Cc: linux-wireless, linux-kernel, Deepanshu Kartikey,
syzbot+56b6a844a4ea74487b7b
NL80211_TDLS_ENABLE_LINK can be called without completing the TDLS
setup handshake, or after the TDLS_PEER_SETUP_TIMEOUT (15 seconds)
has expired and tdls_peer_del_work has zeroed out the peer address.
In both cases the WARN_ON_ONCE triggers because tdls_peer is either
zero or mismatched with the requested peer.
Replace the WARN_ON_ONCE with a proper check that returns -ENOLINK
to enforce that ENABLE_LINK can only proceed after a successful TDLS
handshake.
Reported-by: syzbot+56b6a844a4ea74487b7b@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=56b6a844a4ea74487b7b
Tested-by: syzbot+56b6a844a4ea74487b7b@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
net/mac80211/tdls.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/tdls.c b/net/mac80211/tdls.c
index dbbfe2d6842f..d7d8b2fcc3ee 100644
--- a/net/mac80211/tdls.c
+++ b/net/mac80211/tdls.c
@@ -1457,8 +1457,9 @@ int ieee80211_tdls_oper(struct wiphy *wiphy, struct net_device *dev,
set_sta_flag(sta, WLAN_STA_TDLS_PEER_AUTH);
- WARN_ON_ONCE(is_zero_ether_addr(sdata->u.mgd.tdls_peer) ||
- !ether_addr_equal(sdata->u.mgd.tdls_peer, peer));
+ if (is_zero_ether_addr(sdata->u.mgd.tdls_peer) ||
+ !ether_addr_equal(sdata->u.mgd.tdls_peer, peer))
+ return -ENOLINK;
break;
case NL80211_TDLS_DISABLE_LINK:
/*
--
2.43.0
^ permalink raw reply related
* Re: 6.18.13 iwlwifi deadlock allocating cma while work-item is active.
From: Ben Greear @ 2026-03-10 16:10 UTC (permalink / raw)
To: Tejun Heo
Cc: Johannes Berg, linux-wireless, Miriam Rachel, linux-mm,
linux-kernel
In-Reply-To: <68c1ca1381d1871fff72b211890a64eb@kernel.org>
On 3/4/26 09:14, Tejun Heo wrote:
> Hello,
>
> (Partially drafted with the help of Claude)
>
> On Tue, Mar 03, 2026 at 04:02:14PM -0800, Ben Greear wrote:
>> Could the logic that detects blocked work-queues instead be instrumented
>> to print out more useful information so that just reproducing the problem
>> and providing dmesg output will be sufficient? Or does dmesg already provide
>> enough that would give you a clue as to what is going on?
>
> It may not be exactly the same issue, but Breno just posted a patch that
> might help. The current watchdog only prints backtraces for workers that
> are actively running on CPU, so sleeping culprits are invisible. His
> patch removes that filter so all in-flight workers get printed:
>
> http://lkml.kernel.org/r/aag4tTyeiZyw0jID@gmail.com
>
> Might be worth trying.
Hello Tejun,
I applied the first 4 patches of the v2 of that series to my 6.18.14 kernel, with
my use-kthread-for-regdom patches reverted.
Stock 6.18.16 kernel crashes too often in the wifi driver to reliably reproduce the deadlock
there.
Both the reg_todo and lru_drain are on CPU 5, but I'm not sure if that really
matters.
Does this info below show anything useful to you?
Mar 10 08:59:15 ct523c-2103 kernel: BUG: workqueue lockup - pool cpus=5 node=0 flags=0x0 nice=0 stuck for 57507s!
Mar 10 08:59:15 ct523c-2103 kernel: Showing busy workqueues and worker pools:
Mar 10 08:59:15 ct523c-2103 kernel: workqueue events: flags=0x100
Mar 10 08:59:15 ct523c-2103 kernel: pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
Mar 10 08:59:15 ct523c-2103 kernel: in-flight: 264128:disconnect_work [cfg80211] for 57502s disconnect_work [cfg80211]
Mar 10 08:59:15 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=9 refcnt=10
Mar 10 08:59:15 ct523c-2103 kernel: in-flight: 271323:reg_todo [cfg80211] for 57507s
Mar 10 08:59:15 ct523c-2103 kernel: pending: reg_todo [cfg80211], igb_watchdog_task [igb], output_poll_execute [drm_kms_helper], kernfs_notify_workfn,
key_garbage_collector, 2*update_super_work, netstamp_clear
Mar 10 08:59:15 ct523c-2103 kernel: workqueue events_unbound: flags=0x2
Mar 10 08:59:15 ct523c-2103 kernel: pwq 32: cpus=0-7 flags=0x4 nice=0 active=2 refcnt=3
Mar 10 08:59:15 ct523c-2103 kernel: in-flight: 236337:cfg80211_wiphy_work [cfg80211] for 57507s cfg80211_wiphy_work [cfg80211]
Mar 10 08:59:15 ct523c-2103 kernel: workqueue events_unbound: flags=0x2
Mar 10 08:59:15 ct523c-2103 kernel: pwq 32: cpus=0-7 flags=0x4 nice=0 active=1 refcnt=2
Mar 10 08:59:15 ct523c-2103 kernel: in-flight: 142096:linkwatch_event for 57502s linkwatch_event
Mar 10 08:59:15 ct523c-2103 kernel: pwq 32: cpus=0-7 flags=0x4 nice=0 active=3 refcnt=4
Mar 10 08:59:15 ct523c-2103 kernel: in-flight: 218388:fsnotify_mark_destroy_workfn for 55995s fsnotify_mark_destroy_workfn BAR(1309)
,267638:fsnotify_connector_destroy_workfn for 55995s fsnotify_connector_destroy_workfn
Mar 10 08:59:15 ct523c-2103 kernel: pwq 32: cpus=0-7 flags=0x4 nice=0 active=2 refcnt=4
Mar 10 08:59:15 ct523c-2103 kernel: workqueue events_freezable: flags=0x104
Mar 10 08:59:15 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=1 refcnt=2
Mar 10 08:59:15 ct523c-2103 kernel: pending: pci_pme_list_scan
Mar 10 08:59:15 ct523c-2103 kernel: workqueue events_power_efficient: flags=0x180
Mar 10 08:59:15 ct523c-2103 kernel: pwq 14: cpus=3 node=0 flags=0x0 nice=0 active=2 refcnt=3
Mar 10 08:59:15 ct523c-2103 kernel: in-flight: 268226:reg_check_chans_work [cfg80211] for 57441s reg_check_chans_work [cfg80211]
Mar 10 08:59:15 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=218 refcnt=219
Mar 10 08:59:15 ct523c-2103 kernel: pending: gc_worker [nf_conntrack], hub_post_resume, 216*ioc_release_fn
Mar 10 08:59:15 ct523c-2103 kernel: workqueue rcu_gp: flags=0x108
Mar 10 08:59:15 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=1 refcnt=2
Mar 10 08:59:15 ct523c-2103 kernel: pending: process_srcu
Mar 10 08:59:15 ct523c-2103 kernel: workqueue mm_percpu_wq: flags=0x8
Mar 10 08:59:15 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=2 refcnt=4
Mar 10 08:59:15 ct523c-2103 kernel: pending: lru_add_drain_per_cpu BAR(236337), vmstat_update
Mar 10 08:59:15 ct523c-2103 kernel: workqueue cgroup_offline: flags=0x100
Mar 10 08:59:15 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=1 refcnt=107
Mar 10 08:59:15 ct523c-2103 kernel: pending: css_killed_work_fn
Mar 10 08:59:15 ct523c-2103 kernel: inactive: 105*css_killed_work_fn
Mar 10 08:59:15 ct523c-2103 kernel: workqueue cgroup_release: flags=0x100
Mar 10 08:59:15 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=1 refcnt=15
Mar 10 08:59:15 ct523c-2103 kernel: pending: css_release_work_fn
Mar 10 08:59:15 ct523c-2103 kernel: inactive: 13*css_release_work_fn
Mar 10 08:59:15 ct523c-2103 kernel: workqueue cgroup_bpf_destroy: flags=0x100
Mar 10 08:59:15 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=1 refcnt=54
Mar 10 08:59:15 ct523c-2103 kernel: pending: cgroup_bpf_release
Mar 10 08:59:15 ct523c-2103 kernel: inactive: 52*cgroup_bpf_release
Mar 10 08:59:15 ct523c-2103 kernel: workqueue ipv6_addrconf: flags=0x6000a
Mar 10 08:59:15 ct523c-2103 kernel: pwq 32: cpus=0-7 flags=0x4 nice=0 active=1 refcnt=14
Mar 10 08:59:15 ct523c-2103 kernel: in-flight: 202972:addrconf_dad_work for 57505s
Mar 10 08:59:15 ct523c-2103 kernel: inactive: 4*addrconf_verify_work
Mar 10 08:59:15 ct523c-2103 kernel: pool 2: cpus=0 node=0 flags=0x0 nice=0 hung=0s workers=3 idle: 203067 243191
Mar 10 08:59:15 ct523c-2103 kernel: pool 14: cpus=3 node=0 flags=0x0 nice=0 hung=0s workers=3 idle: 709498 699449
Mar 10 08:59:15 ct523c-2103 kernel: pool 22: cpus=5 node=0 flags=0x0 nice=0 hung=57507s workers=3 idle: 166929 260518
Mar 10 08:59:15 ct523c-2103 kernel: pool 32: cpus=0-7 flags=0x4 nice=0 hung=0s workers=9 idle: 631693 712021 717023 671858
Mar 10 08:59:15 ct523c-2103 kernel: Showing backtraces of busy workers in stalled CPU-bound worker pools:
Mar 10 08:59:15 ct523c-2103 kernel: pool 22:
Mar 10 08:59:15 ct523c-2103 kernel: task:kworker/5:2 state:D stack:0 pid:271323 tgid:271323 ppid:2 task_flags:0x4208060 flags:0x00080000
Mar 10 08:59:15 ct523c-2103 kernel: Workqueue: events reg_todo [cfg80211]
Mar 10 08:59:15 ct523c-2103 kernel: Call Trace:
Mar 10 08:59:15 ct523c-2103 kernel: <TASK>
Mar 10 08:59:15 ct523c-2103 kernel: __schedule+0x106f/0x4340
Mar 10 08:59:15 ct523c-2103 kernel: ? lock_acquire+0x155/0x2e0
Mar 10 08:59:15 ct523c-2103 kernel: ? io_schedule_timeout+0x150/0x150
Mar 10 08:59:15 ct523c-2103 kernel: ? __schedule+0x1865/0x4340
Mar 10 08:59:15 ct523c-2103 kernel: preempt_schedule_notrace+0x4c/0x70
Mar 10 08:59:15 ct523c-2103 kernel: preempt_schedule_notrace_thunk+0x16/0x30
Mar 10 08:59:15 ct523c-2103 kernel: rcu_is_watching+0x59/0x70
Mar 10 08:59:15 ct523c-2103 kernel: lock_acquire+0x291/0x2e0
Mar 10 08:59:15 ct523c-2103 kernel: schedule+0x211/0x3a0
Mar 10 08:59:15 ct523c-2103 kernel: ? schedule+0x1f2/0x3a0
Mar 10 08:59:15 ct523c-2103 kernel: schedule_preempt_disabled+0x11/0x20
Mar 10 08:59:15 ct523c-2103 kernel: __mutex_lock+0xd02/0x1d60
Mar 10 08:59:15 ct523c-2103 kernel: ? reg_process_self_managed_hints+0x70/0x190 [cfg80211]
Mar 10 08:59:15 ct523c-2103 kernel: ? ww_mutex_lock+0x160/0x160
Mar 10 08:59:15 ct523c-2103 kernel: ? __mutex_unlock_slowpath+0x15d/0x770
Mar 10 08:59:15 ct523c-2103 kernel: ? wait_for_completion_io_timeout+0x20/0x20
Mar 10 08:59:15 ct523c-2103 kernel: ? reg_process_self_managed_hints+0x70/0x190 [cfg80211]
Mar 10 08:59:15 ct523c-2103 kernel: reg_process_self_managed_hints+0x70/0x190 [cfg80211]
Mar 10 08:59:15 ct523c-2103 kernel: reg_todo+0x52e/0x7c0 [cfg80211]
Mar 10 08:59:15 ct523c-2103 kernel: ? lock_release+0xce/0x290
Mar 10 08:59:15 ct523c-2103 kernel: process_one_work+0x88b/0x1820
Mar 10 08:59:15 ct523c-2103 kernel: ? pwq_dec_nr_in_flight+0xe00/0xe00
Mar 10 08:59:15 ct523c-2103 kernel: ? reg_process_hint+0x1480/0x1480 [cfg80211]
Mar 10 08:59:15 ct523c-2103 kernel: worker_thread+0x5a1/0xfd0
Mar 10 08:59:15 ct523c-2103 kernel: ? __kthread_parkme+0xc6/0x1f0
Mar 10 08:59:15 ct523c-2103 kernel: ? rescuer_thread+0x1350/0x1350
Mar 10 08:59:15 ct523c-2103 kernel: kthread+0x3b7/0x770
Mar 10 08:59:15 ct523c-2103 kernel: ? kthread_is_per_cpu+0xb0/0xb0
Mar 10 08:59:15 ct523c-2103 kernel: ? ret_from_fork+0x17/0x3a0
Mar 10 08:59:15 ct523c-2103 kernel: ? lock_release+0xce/0x290
Mar 10 08:59:15 ct523c-2103 kernel: ? kthread_is_per_cpu+0xb0/0xb0
Mar 10 08:59:15 ct523c-2103 kernel: ret_from_fork+0x28b/0x3a0
Mar 10 08:59:15 ct523c-2103 kernel: ? kthread_is_per_cpu+0xb0/0xb0
Mar 10 08:59:15 ct523c-2103 kernel: ret_from_fork_asm+0x11/0x20
Mar 10 08:59:15 ct523c-2103 kernel: </TASK>
Mar 10 08:59:46 ct523c-2103 kernel: BUG: workqueue lockup - pool cpus=5 node=0 flags=0x0 nice=0 stuck for 57537s!
Mar 10 08:59:46 ct523c-2103 kernel: Showing busy workqueues and worker pools:
Mar 10 08:59:46 ct523c-2103 kernel: workqueue events: flags=0x100
Mar 10 08:59:46 ct523c-2103 kernel: pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
Mar 10 08:59:46 ct523c-2103 kernel: in-flight: 264128:disconnect_work [cfg80211] for 57533s disconnect_work [cfg80211]
Mar 10 08:59:46 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=9 refcnt=10
Mar 10 08:59:46 ct523c-2103 kernel: in-flight: 271323:reg_todo [cfg80211] for 57537s
Mar 10 08:59:46 ct523c-2103 kernel: pending: reg_todo [cfg80211], igb_watchdog_task [igb], output_poll_execute [drm_kms_helper], kernfs_notify_workfn,
key_garbage_collector, 2*update_super_work, netstamp_clear
Mar 10 08:59:46 ct523c-2103 kernel: workqueue events_unbound: flags=0x2
Mar 10 08:59:46 ct523c-2103 kernel: pwq 32: cpus=0-7 flags=0x4 nice=0 active=2 refcnt=3
Mar 10 08:59:46 ct523c-2103 kernel: in-flight: 236337:cfg80211_wiphy_work [cfg80211] for 57537s cfg80211_wiphy_work [cfg80211]
Mar 10 08:59:46 ct523c-2103 kernel: workqueue events_unbound: flags=0x2
Mar 10 08:59:46 ct523c-2103 kernel: pwq 32: cpus=0-7 flags=0x4 nice=0 active=1 refcnt=2
Mar 10 08:59:46 ct523c-2103 kernel: in-flight: 142096:linkwatch_event for 57533s linkwatch_event
Mar 10 08:59:46 ct523c-2103 kernel: pwq 32: cpus=0-7 flags=0x4 nice=0 active=3 refcnt=4
Mar 10 08:59:46 ct523c-2103 kernel: in-flight: 218388:fsnotify_mark_destroy_workfn for 56026s fsnotify_mark_destroy_workfn BAR(1309)
,267638:fsnotify_connector_destroy_workfn for 56026s fsnotify_connector_destroy_workfn
Mar 10 08:59:46 ct523c-2103 kernel: pwq 32: cpus=0-7 flags=0x4 nice=0 active=2 refcnt=4
Mar 10 08:59:46 ct523c-2103 kernel: workqueue events_freezable: flags=0x104
Mar 10 08:59:46 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=1 refcnt=2
Mar 10 08:59:46 ct523c-2103 kernel: pending: pci_pme_list_scan
Mar 10 08:59:46 ct523c-2103 kernel: workqueue events_power_efficient: flags=0x180
Mar 10 08:59:46 ct523c-2103 kernel: pwq 14: cpus=3 node=0 flags=0x0 nice=0 active=2 refcnt=3
Mar 10 08:59:46 ct523c-2103 kernel: in-flight: 268226:reg_check_chans_work [cfg80211] for 57472s reg_check_chans_work [cfg80211]
Mar 10 08:59:46 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=218 refcnt=219
Mar 10 08:59:46 ct523c-2103 kernel: pending: gc_worker [nf_conntrack], hub_post_resume, 216*ioc_release_fn
Mar 10 08:59:46 ct523c-2103 kernel: workqueue rcu_gp: flags=0x108
Mar 10 08:59:46 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=1 refcnt=2
Mar 10 08:59:46 ct523c-2103 kernel: pending: process_srcu
Mar 10 08:59:46 ct523c-2103 kernel: workqueue mm_percpu_wq: flags=0x8
Mar 10 08:59:46 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=2 refcnt=4
Mar 10 08:59:46 ct523c-2103 kernel: pending: lru_add_drain_per_cpu BAR(236337), vmstat_update
Mar 10 08:59:46 ct523c-2103 kernel: workqueue cgroup_offline: flags=0x100
Mar 10 08:59:46 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=1 refcnt=107
Mar 10 08:59:46 ct523c-2103 kernel: pending: css_killed_work_fn
Mar 10 08:59:46 ct523c-2103 kernel: inactive: 105*css_killed_work_fn
Mar 10 08:59:46 ct523c-2103 kernel: workqueue cgroup_release: flags=0x100
Mar 10 08:59:46 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=1 refcnt=15
Mar 10 08:59:46 ct523c-2103 kernel: pending: css_release_work_fn
Mar 10 08:59:46 ct523c-2103 kernel: inactive: 13*css_release_work_fn
Mar 10 08:59:46 ct523c-2103 kernel: workqueue cgroup_bpf_destroy: flags=0x100
Mar 10 08:59:46 ct523c-2103 kernel: pwq 22: cpus=5 node=0 flags=0x0 nice=0 active=1 refcnt=54
Mar 10 08:59:46 ct523c-2103 kernel: pending: cgroup_bpf_release
Mar 10 08:59:46 ct523c-2103 kernel: inactive: 52*cgroup_bpf_release
Mar 10 08:59:46 ct523c-2103 kernel: workqueue ipv6_addrconf: flags=0x6000a
Mar 10 08:59:46 ct523c-2103 kernel: pwq 32: cpus=0-7 flags=0x4 nice=0 active=1 refcnt=14
Mar 10 08:59:46 ct523c-2103 kernel: in-flight: 202972:addrconf_dad_work for 57536s
Mar 10 08:59:46 ct523c-2103 kernel: inactive: 4*addrconf_verify_work
Mar 10 08:59:46 ct523c-2103 kernel: pool 2: cpus=0 node=0 flags=0x0 nice=0 hung=0s workers=3 idle: 203067 243191
Mar 10 08:59:46 ct523c-2103 kernel: pool 14: cpus=3 node=0 flags=0x0 nice=0 hung=0s workers=3 idle: 709498 699449
Mar 10 08:59:46 ct523c-2103 kernel: pool 22: cpus=5 node=0 flags=0x0 nice=0 hung=57537s workers=3 idle: 166929 260518
Mar 10 08:59:46 ct523c-2103 kernel: pool 32: cpus=0-7 flags=0x4 nice=0 hung=0s workers=9 idle: 631693 712021 717023 671858
Mar 10 08:59:46 ct523c-2103 kernel: Showing backtraces of busy workers in stalled CPU-bound worker pools:
Mar 10 08:59:46 ct523c-2103 kernel: pool 22:
Mar 10 08:59:46 ct523c-2103 kernel: task:kworker/5:2 state:D stack:0 pid:271323 tgid:271323 ppid:2 task_flags:0x4208060 flags:0x00080000
Mar 10 08:59:46 ct523c-2103 kernel: Workqueue: events reg_todo [cfg80211]
Mar 10 08:59:46 ct523c-2103 kernel: Call Trace:
Mar 10 08:59:46 ct523c-2103 kernel: <TASK>
Mar 10 08:59:46 ct523c-2103 kernel: __schedule+0x106f/0x4340
Mar 10 08:59:46 ct523c-2103 kernel: ? lock_acquire+0x155/0x2e0
Mar 10 08:59:46 ct523c-2103 kernel: ? io_schedule_timeout+0x150/0x150
Mar 10 08:59:46 ct523c-2103 kernel: ? __schedule+0x1865/0x4340
Mar 10 08:59:46 ct523c-2103 kernel: preempt_schedule_notrace+0x4c/0x70
Mar 10 08:59:46 ct523c-2103 kernel: preempt_schedule_notrace_thunk+0x16/0x30
Mar 10 08:59:46 ct523c-2103 kernel: rcu_is_watching+0x59/0x70
Mar 10 08:59:46 ct523c-2103 kernel: lock_acquire+0x291/0x2e0
Mar 10 08:59:46 ct523c-2103 kernel: schedule+0x211/0x3a0
Mar 10 08:59:46 ct523c-2103 kernel: ? schedule+0x1f2/0x3a0
Mar 10 08:59:46 ct523c-2103 kernel: schedule_preempt_disabled+0x11/0x20
Mar 10 08:59:46 ct523c-2103 kernel: __mutex_lock+0xd02/0x1d60
Mar 10 08:59:46 ct523c-2103 kernel: ? reg_process_self_managed_hints+0x70/0x190 [cfg80211]
Mar 10 08:59:46 ct523c-2103 kernel: ? ww_mutex_lock+0x160/0x160
Mar 10 08:59:46 ct523c-2103 kernel: ? __mutex_unlock_slowpath+0x15d/0x770
Mar 10 08:59:46 ct523c-2103 kernel: ? wait_for_completion_io_timeout+0x20/0x20
Mar 10 08:59:46 ct523c-2103 kernel: ? reg_process_self_managed_hints+0x70/0x190 [cfg80211]
Mar 10 08:59:46 ct523c-2103 kernel: reg_process_self_managed_hints+0x70/0x190 [cfg80211]
Mar 10 08:59:46 ct523c-2103 kernel: reg_todo+0x52e/0x7c0 [cfg80211]
Mar 10 08:59:46 ct523c-2103 kernel: ? lock_release+0xce/0x290
Mar 10 08:59:46 ct523c-2103 kernel: process_one_work+0x88b/0x1820
Mar 10 08:59:46 ct523c-2103 kernel: ? pwq_dec_nr_in_flight+0xe00/0xe00
Mar 10 08:59:46 ct523c-2103 kernel: ? reg_process_hint+0x1480/0x1480 [cfg80211]
Mar 10 08:59:46 ct523c-2103 kernel: worker_thread+0x5a1/0xfd0
Mar 10 08:59:46 ct523c-2103 kernel: ? __kthread_parkme+0xc6/0x1f0
Mar 10 08:59:46 ct523c-2103 kernel: ? rescuer_thread+0x1350/0x1350
Mar 10 08:59:46 ct523c-2103 kernel: kthread+0x3b7/0x770
Mar 10 08:59:46 ct523c-2103 kernel: ? kthread_is_per_cpu+0xb0/0xb0
Mar 10 08:59:46 ct523c-2103 kernel: ? ret_from_fork+0x17/0x3a0
Mar 10 08:59:46 ct523c-2103 kernel: ? lock_release+0xce/0x290
Mar 10 08:59:46 ct523c-2103 kernel: ? kthread_is_per_cpu+0xb0/0xb0
Mar 10 08:59:46 ct523c-2103 kernel: ret_from_fork+0x28b/0x3a0
Mar 10 08:59:46 ct523c-2103 kernel: ? kthread_is_per_cpu+0xb0/0xb0
Mar 10 08:59:46 ct523c-2103 kernel: ret_from_fork_asm+0x11/0x20
Mar 10 08:59:46 ct523c-2103 kernel: </TASK>
>> If I were to attempt to use AI on the coredump, would echoing 'c' to
>> /proc/sysrq-trigger with kdump enabled (when deadlock is happening) be
>> the appropriate action to grab the core file?
>
> Yes, that's right, but you need to set up kdump first. The quickest way
> depends on your distro:
>
> - Fedora/RHEL: dnf install kexec-tools, then kdumpctl reset-crashkernel,
> systemctl enable --now kdump
> - Ubuntu/Debian: apt install kdump-tools (say Yes to enable), reboot
> - Arch: Install kexec-tools, add crashkernel=512M to your kernel
> cmdline, create a kdump.service that runs
> kexec -p /boot/vmlinuz-linux --initrd=/boot/initramfs-linux.img \
> --append="root=<your-root> irqpoll nr_cpus=1 reset_devices"
>
> After reboot, verify with: cat /sys/kernel/kexec_crash_size (should be
> non-zero). Then when the deadlock happens:
>
> echo c > /proc/sysrq-trigger
I have kdump enabled already, and I could create a vmcore like this.
I have never used drgn, nor claude. Based on the logs above, do
you still think it would be helpful to try drgn? If so, can you please
suggest some commands or approaches specific to this particular bug?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] wifi: wlcore: ensure skb headroom before skb_push
From: Guenter Roeck @ 2026-03-10 16:34 UTC (permalink / raw)
To: Peter Åstrand; +Cc: linux-wireless
In-Reply-To: <6895624e-22f8-d533-5167-e32de031e369@lysator.liu.se>
On 3/10/26 08:52, Peter Åstrand wrote:
> On Wed, 25 Feb 2026, Guenter Roeck wrote:
>
>> Hi,
>>
>> On Wed, Dec 03, 2025 at 08:57:08AM +0100, Peter Åstrand wrote:
>>>
>>> This avoids occasional skb_under_panic Oops from wl1271_tx_work. In this case, headroom is
>>> less than needed (typically 110 - 94 = 16 bytes).
>>>
>>> Signed-off-by: Peter Astrand <astrand@lysator.liu.se>
>>> ---
>>> drivers/net/wireless/ti/wlcore/tx.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ti/wlcore/tx.c b/drivers/net/wireless/ti/wlcore/tx.c
>>> index f76087be2f75..6241866d39df 100644
>>> --- a/drivers/net/wireless/ti/wlcore/tx.c
>>> +++ b/drivers/net/wireless/ti/wlcore/tx.c
>>> @@ -207,6 +207,11 @@ static int wl1271_tx_allocate(struct wl1271 *wl, struct wl12xx_vif *wlvif,
>>> total_blocks = wlcore_hw_calc_tx_blocks(wl, total_len, spare_blocks);
>>>
>>> if (total_blocks <= wl->tx_blocks_available) {
>>> + if (skb_headroom(skb) < (total_len - skb->len) &&
>>> + pskb_expand_head(skb, (total_len - skb->len), 0, GFP_ATOMIC)) {
>>> + wl1271_free_tx_id(wl, id);
>>> + return -EAGAIN;
>>> + }
>>
>> An experimental AI code review agent provided the following feedback:
>>
>> If pskb_expand_head() fails, the code returns -EAGAIN. However, in
>> wlcore_tx_work_locked(), a return value of -EAGAIN from
>> wl1271_prepare_tx_frame() is interpreted as the aggregation buffer being full.
>> This causes the code to flush the buffer, put the skb back at the head of the
>> queue, and immediately retry the same skb in a tight while loop.
>>
>> Because wlcore_tx_work_locked() holds wl->mutex, and the retry happens
>> immediately with GFP_ATOMIC, will this result in an infinite loop and a CPU
>> soft lockup? Should this return -ENOMEM instead, so the packet is dropped and
>> the loop terminates?
>>
>> I don't understand the code well enough to understand if the AI agent has a
>> point or not. Please take a look and let me know if this is a real problem.
>
> From my perspective, this makes sense. We have never seen any CPU soft
> lockup, but perhaps pskb_expand_head() never fails on our systems. ath12k
> also returns -ENOMEM when pskb_expand_head() fails.
>
> Can you submit a patch?
>
Sure.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v3 0/3] Replace uses of system_wq and system_unbound_wq
From: Marco Crivellari @ 2026-03-10 16:37 UTC (permalink / raw)
To: linux-kernel, linux-wireless
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Michal Hocko, Miri Korenblit,
Johannes Berg
In-Reply-To: <20260210143332.206146-1-marco.crivellari@suse.com>
On Tue, Feb 10, 2026 at 3:33 PM Marco Crivellari
<marco.crivellari@suse.com> wrote:
> [...]
> Marco Crivellari (3):
> wifi: iwlwifi: replace use of system_unbound_wq with system_dfl_wq
> wifi: iwlwifi: fw: replace use of system_unbound_wq with system_dfl_wq
> wifi: iwlwifi: mvm: replace use of system_wq with system_percpu_wq
>
> drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 4 ++--
> drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 2 +-
> drivers/net/wireless/intel/iwlwifi/mvm/tdls.c | 6 +++---
> 3 files changed, 6 insertions(+), 6 deletions(-)
Hi,
Gentle ping.
Thanks!
--
Marco Crivellari
L3 Support Engineer
^ permalink raw reply
* Re: [PATCH] wifi: rtw89: retry efuse physical map dump on transient failure
From: Christian Hewitt @ 2026-03-10 17:16 UTC (permalink / raw)
To: Ping-Ke Shih
Cc: Bitterblue Smith, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <5ad1b7d20d1745bab0638d15731e7ccd@realtek.com>
> On 9 Mar 2026, at 6:35 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Christian Hewitt <christianshewitt@gmail.com> wrote:
>>
>>> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>>>
>>> Christian Hewitt <christianshewitt@gmail.com> wrote:
>>>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>>>>>
>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote:
>>>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse
>>>>>> physical map dump intermittently fails with -EBUSY during probe.
>>>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where
>>>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY
>>>>>> bit after 1 second.
>>>>>
>>>>> I'm checking internally how we handle this case.
>
> Sorry for the late.
>
> We encountered WiFi/BT reading efuse at the same time causing similar
> problem as yours. The workaround is like yours, which adds timeout
> time.
>
>>>>>
>>>>> [...]
>>>>>
>>>>>>
>>>>>> For context, firmware also fails (and recovers) sometimes:
>>>>>
>>>>> Did you mean this doesn't always happen? sometimes?
>>>>
>>>> It’s another intermittent behaviour observed on this board (and not
>>>> related to the issue this patch targets). It occurs less frequently
>>>> than the efuse issue and the existing retry mechanism in the driver
>>>> ensures firmware load always succeeds.
>
> This might be the same cause due to reading efuse in firmware.
>
> Though we can add more timeout and retry times as workaround, I wonder
> if you can control loading time of WiFi and BT kernel modules?
>
> More, can you do experiment that you load BT module first, and then load
> WiFi module after 10 seconds (choose a large number intentionally, or
> even larger)?
https://paste.libreelec.tv/charmed-turkey.sh
I’ve run the above script ^ which removes the wifi and bt modules in
sequence then reloads them in the reverse order with a delay between
bt and wifi modules loading, then checks for error messages. Over 200
test cycles with a 10s delay all were clean (no errors). I also ran
cycles with a 2 second delay and 0 second delay before starting wifi
module load and those were clear too. I guess that proves sequencing
avoids the efuse contention issue? - although it’s not possible in
the real-world so not sure there’s huge value in knowing that :)
Christian
^ permalink raw reply
* Re: [PATCH v3] wifi: ath12k: fix endianness handling for SRNG ring pointer accesses
From: Jeff Johnson @ 2026-03-10 17:55 UTC (permalink / raw)
To: Alexander Wilhelm, Jeff Johnson
Cc: Baochen Qiang, ath12k, linux-wireless, linux-kernel
In-Reply-To: <20260119073923.764245-1-alexander.wilhelm@westermo.com>
On 1/18/2026 11:39 PM, Alexander Wilhelm wrote:
> The SRNG head and tail ring pointers are stored in device memory as
> little-endian values. On big-endian systems, direct dereferencing of these
> pointers leads to incorrect values being read or written, causing ring
> management issues and potentially breaking data flow.
>
> This patch ensures all accesses to SRNG ring pointers use the appropriate
> endianness conversions. This affects both read and write paths for source
> and destination rings, as well as debug output. The changes guarantee
> correct operation on both little- and big-endian architectures.
>
> Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
> ---
> Changes in v3:
> - Rebase on latest 'ath' master
> - Use always 'le32_to_cpu()' macro for conversions
>
> Changes in v2:
> - Set '__le32 *' type for 'hp_addr/tp_addr' in both 'dst_ring' and 'src_ring'
> ---
> drivers/net/wireless/ath/ath12k/hal.c | 37 +++++++++++++++------------
> drivers/net/wireless/ath/ath12k/hal.h | 8 +++---
> 2 files changed, 25 insertions(+), 20 deletions(-)
I really hope to get your changes in.
With your changes sparse reports:
drivers/net/wireless/ath/ath12k/wifi7/hal.c:322:50: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath12k/wifi7/hal.c:322:50: expected restricted __le32 [usertype] *hp_addr
drivers/net/wireless/ath/ath12k/wifi7/hal.c:322:50: got unsigned int [usertype] *
drivers/net/wireless/ath/ath12k/wifi7/hal.c:333:50: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath12k/wifi7/hal.c:333:50: expected restricted __le32 [usertype] *tp_addr
drivers/net/wireless/ath/ath12k/wifi7/hal.c:333:50: got unsigned int [usertype] *
drivers/net/wireless/ath/ath12k/wifi7/hal.c:387:42: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath12k/wifi7/hal.c:387:42: expected restricted __le32 [usertype] *tp_addr
drivers/net/wireless/ath/ath12k/wifi7/hal.c:387:42: got unsigned int [usertype] *
drivers/net/wireless/ath/ath12k/wifi7/hal.c:390:42: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath12k/wifi7/hal.c:390:42: expected restricted __le32 [usertype] *hp_addr
drivers/net/wireless/ath/ath12k/wifi7/hal.c:390:42: got unsigned int [usertype] *
I'm also getting checkpatch issues:
drivers/net/wireless/ath/ath12k/hal.c:503: Lines should not end with a '('
drivers/net/wireless/ath/ath12k/hal.c:531: Lines should not end with a '('
drivers/net/wireless/ath/ath12k/hal.c:551: Lines should not end with a '('
Can you address these issues?
/jeff
^ permalink raw reply
* Re: 6.18.13 iwlwifi deadlock allocating cma while work-item is active.
From: Tejun Heo @ 2026-03-10 18:06 UTC (permalink / raw)
To: Ben Greear
Cc: Johannes Berg, linux-wireless, Miriam Rachel, linux-mm,
linux-kernel
In-Reply-To: <bba74cab-7305-a052-7e1c-7a7736ba4531@candelatech.com>
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
Hello,
Thanks for the detailed dump. One thing that doesn't look right is the
number of pending work items on pool 22 (CPU 5). The pool reports 2 idle
workers, yet there are 7+ work items sitting in the pending list across
multiple workqueues. If the pool were making forward progress, those items
would have been picked up by the idle workers. So, the pool itself seems to
be stuck for some reason, and the cfg80211 mutex stall may be a consequence
rather than the cause.
Let's try using drgn on the crash dump. I'm attaching a prompt that you can
feed to Claude (or any LLM with tool access to drgn). It contains workqueue
internals documentation, drgn code snippets, and a systematic investigation
procedure. The idea is:
1. Generate the crash dump when the deadlock is happening:
echo c > /proc/sysrq-trigger
2. After the crash kernel boots, create the dump file:
makedumpfile -c -d 31 /proc/vmcore /tmp/vmcore.dmp
3. Feed the attached prompt to Claude with drgn access to the dump. It
should produce a Markdown report with its findings that you can post
back here.
This is a bit experimental, so let's see whether it works. Either way, the
report should at least give us concrete data points to work with.
Thanks.
--
tejun
[-- Attachment #2: wq-drgn-prompt.txt --]
[-- Type: text/plain, Size: 27606 bytes --]
# Workqueue Lockup Investigation with drgn
You are investigating a Linux kernel workqueue lockup using drgn on a crash
dump. The system reported a workqueue pool stall on CPU 5 with `reg_todo`
[cfg80211] stuck for ~57500 seconds. Your job is to determine the root cause.
## HOW TO RUN DRGN
```bash
# Install drgn (if not already installed):
# pip3 install drgn
# OR on Fedora: dnf install drgn
# Run drgn on a crash dump:
drgn -c /path/to/vmcore
# If symbols aren't found automatically, point to the vmlinux:
drgn -c /path/to/vmcore -s /path/to/vmlinux
# For modules, point to the module directory:
drgn -c /path/to/vmcore -s /path/to/vmlinux -s /lib/modules/$(uname -r)/
# Inside drgn, 'prog' is the program object. You can run Python interactively
# or pass a script with -e or -s:
drgn -c /path/to/vmcore -s /path/to/vmlinux -e 'print(prog["jiffies"])'
```
All code blocks in this document are Python code to run inside the drgn
interactive shell or via `-e`.
## METHODOLOGY — READ THIS FIRST
**CRITICAL RULES — violating these will produce wrong conclusions:**
1. **NEVER jump on any specific lead without concrete evidence.** Do not
assume you know the answer from the dmesg alone. The dmesg gives you a
starting point, not a conclusion.
2. **Draw conclusions if and only if the hard facts support them.** Every
claim you make must be backed by specific drgn output — an address, a
value, a stack trace. If you cannot show the evidence, say "I don't have
evidence for this" and move on.
3. **Present results and thought process with specific, concrete evidence.**
Show the drgn commands you ran and the relevant output. Then explain what
that output means. Evidence first, interpretation second.
4. **Think holistically — do NOT separate workqueue stall from lock stalls.**
A stuck workqueue pool can CAUSE what looks like deadlocks elsewhere.
Work items that are expected to run but cannot (because the pool is
stuck) will stall anything waiting on their completion. A mutex holder
might be waiting for a work item that will never run. What looks like a
"deadlock" might actually be a consequence of the pool stall, not the
cause. Always consider both directions of causality.
5. **Check everything systematically.** Do not skip steps because you think
you already know the answer. Complete Phase 1 fully before moving to
Phase 2. If the pool has multiple pending work items that are not being
processed, the pool IS stuck — do not dismiss this as "a transient
snapshot."
## WORKQUEUE ARCHITECTURE
### Overview
The Linux workqueue subsystem processes deferred work using kernel threads
(workers) organized into pools:
- **worker_pool**: A group of kernel threads (workers) that share a worklist.
Each CPU has two standard pools: pool[0] (normal priority) and pool[1]
(high priority). Unbound pools serve work not tied to a specific CPU.
- **workqueue_struct**: A named workqueue (e.g., "events",
"events_power_efficient"). Each workqueue connects to pools via
pool_workqueue (pwq) structures — one pwq per pool the workqueue uses.
Multiple workqueues share the same underlying pool.
- **pool_workqueue (pwq)**: Links a workqueue to a pool. Tracks nr_active
(how many work items from this workqueue are active in the pool) and
enforces max_active limits. Work items exceeding max_active go to
pwq->inactive_works instead of pool->worklist.
- **worker**: A kernel thread that picks work from pool->worklist and
executes it. Workers are either idle (on pool->idle_list) or busy
(in pool->busy_hash, executing a work item).
### Concurrency Management (CMWQ)
For bound (per-CPU) pools, the workqueue uses a concurrency management
protocol based on `pool->nr_running`:
- **nr_running** counts workers actively running on CPU (not sleeping, not
idle, not marked CPU_INTENSIVE).
- When a worker sleeps (e.g., waiting on a mutex), the scheduler calls
`wq_worker_sleeping()` which decrements nr_running. If nr_running hits 0
and there is pending work, `kick_pool()` wakes an idle worker.
- When a worker wakes up, `wq_worker_running()` increments nr_running.
- The decision functions:
- `need_more_worker(pool)`: `!list_empty(&pool->worklist) && !pool->nr_running`
— need a worker if work is pending AND nobody is running.
- `may_start_working(pool)`: `pool->nr_idle` — can proceed only if there
are idle workers remaining (so there's always a reserve).
- `keep_working(pool)`: `!list_empty(&pool->worklist) && pool->nr_running <= 1`
— current worker keeps going if work pending and it's the only runner.
- **Key insight**: If nr_running > 0, the pool assumes someone is handling
work and does NOT wake idle workers, even if work is pending. A stuck
nr_running > 0 with no worker actually on CPU would prevent all forward
progress.
### Worker Lifecycle and the 2-Idle-Worker Invariant
The worker_thread() main loop:
1. Wake up, leave idle state (nr_idle--)
2. Check `need_more_worker()` — if no work or nr_running > 0, go to sleep
3. Check `may_start_working()` — if nr_idle == 0, become manager and create
new workers before proceeding
4. Clear PREP flag, enter concurrency management (nr_running++)
5. Process work items from pool->worklist in a loop
6. When done, enter idle state (nr_idle++) and sleep
**The 2-idle-worker invariant**: The pool maintains at least 2 idle workers
(enforced by `too_many_workers()` which only culls when nr_idle > 2). This
ensures that when one idle worker wakes to process work (step 1: nr_idle--),
there is still at least one idle worker remaining. If nr_idle hits 0, the
woken worker must become the "manager" and create new workers before it can
process any work.
**Worker creation** (`create_worker()`): Allocates memory with GFP_KERNEL
and calls `kthread_create_on_node()`. Both operations can stall indefinitely
if the system is under memory pressure and reclaim is not making progress.
GFP_KERNEL allocations will not fail — they block in the allocator waiting
for pages. If memory reclaim is broken for any reason, `create_worker()` will
hang forever. This would prevent the pool from recovering if it runs out of
idle workers.
**Mayday/rescuer mechanism**: If `create_worker()` cannot make progress, the
pool's mayday_timer fires and sends distress signals to workqueues that have
WQ_MEM_RECLAIM set. Those workqueues have a dedicated rescuer thread that
can process their work items without needing new workers. However, regular
workqueues like "events" do NOT have rescuers — if they run out of workers,
they are stuck.
### Watchdog
The pool watchdog checks whether pool->watchdog_ts has advanced. watchdog_ts
is updated each time a worker picks up a new work item from the worklist.
If watchdog_ts hasn't advanced for wq_watchdog_thresh seconds (default 30),
the pool is considered stalled. The "hung=Ns" in the stall warning shows
`jiffies - pool->watchdog_ts` converted to seconds.
## DATA STRUCTURE REFERENCE (for drgn)
### Accessing Pools
```python
from drgn.helpers.linux.percpu import per_cpu
from drgn.helpers.linux.list import list_for_each_entry
from drgn import Object, cast
# Per-CPU normal-priority pool for CPU N:
pool = per_cpu(prog["cpu_worker_pools"], cpu)[0]
# Per-CPU high-priority pool for CPU N:
pool = per_cpu(prog["cpu_worker_pools"], cpu)[1]
```
### worker_pool fields
```
pool.cpu — int, associated CPU (-1 for unbound)
pool.id — int, pool ID
pool.nr_running — int, workers currently running on CPU
pool.nr_workers — int, total workers
pool.nr_idle — int, currently idle workers
pool.worklist — list_head, pending work items
pool.idle_list — list_head, idle workers
pool.workers — list_head, all workers (iterate via "node" member)
pool.busy_hash — hashtable of busy workers
pool.manager — struct worker *, current manager (or NULL)
pool.flags — uint: POOL_MANAGER_ACTIVE=0x2, POOL_DISASSOCIATED=0x4
pool.watchdog_ts — unsigned long, jiffies of last forward progress
pool.cpu_stall — bool, set by watchdog when stalled
```
### worker fields (iterate via pool.workers, link member "node")
```
worker.task — struct task_struct *, the kthread
worker.current_work — struct work_struct *, work being executed (NULL if idle)
worker.current_func — work_func_t, function of current work
worker.current_pwq — struct pool_workqueue *, pwq of current work
worker.current_at — u64, ktime at start of current work
worker.sleeping — int, 1 if worker went to sleep (decremented nr_running)
worker.flags — uint: WORKER_DIE=0x2, WORKER_IDLE=0x4, WORKER_PREP=0x8,
WORKER_CPU_INTENSIVE=0x40, WORKER_UNBOUND=0x80
worker.id — int, worker ID (shows in task name as kworker/CPU:ID)
worker.last_active — unsigned long, jiffies of last activity
worker.pool — struct worker_pool *, associated pool
worker.scheduled — list_head, scheduled works for this worker
```
### work_struct fields (iterate via pool.worklist, link member "entry")
```
work.data — atomic_long_t, encodes pwq pointer + flags
work.func — work_func_t, the function to execute
work.entry — list_head, linkage in worklist
# Extracting pwq from work->data:
data = work.data.counter.value_()
WORK_STRUCT_PWQ_BIT = 1 << 2
WORK_STRUCT_PWQ_SHIFT = 8 # bits 0-7 are flags, bits 8+ are pwq pointer
if data & WORK_STRUCT_PWQ_BIT:
pwq_addr = data & ~((1 << WORK_STRUCT_PWQ_SHIFT) - 1)
pwq = Object(prog, "struct pool_workqueue", address=pwq_addr)
wq_name = pwq.wq.name.string_().decode()
```
### pool_workqueue fields
```
pwq.pool — struct worker_pool *, the pool
pwq.wq — struct workqueue_struct *, the workqueue
pwq.nr_active — int, active work items from this wq in this pool
pwq.inactive_works — list_head, work items waiting for nr_active < max_active
pwq.stats[] — u64 array: [0]=STARTED, [1]=COMPLETED, [2]=CPU_TIME,
[3]=CPU_INTENSIVE, [4]=CM_WAKEUP, [5]=REPATRIATED,
[6]=MAYDAY, [7]=RESCUED
```
### workqueue_struct fields
```
wq.name — char[], workqueue name
wq.flags — uint, WQ_UNBOUND=0x2, WQ_FREEZABLE=0x4,
WQ_MEM_RECLAIM=0x8, WQ_HIGHPRI=0x10
wq.max_active — int, max concurrent work items per pwq
wq.cpu_pwq — per-cpu pointer to pwqs (for bound workqueues)
wq.pwqs — list_head, all pwqs (iterate via "pwqs_node")
wq.rescuer — struct worker * (non-NULL if WQ_MEM_RECLAIM)
```
### Mutex inspection
```python
# struct mutex has an owner field (atomic_long_t)
# Low 3 bits are flags, remaining bits are task_struct pointer
owner_val = mutex.owner.counter.value_()
owner_ptr = owner_val & ~0x7
if owner_ptr:
owner_task = Object(prog, "struct task_struct", address=owner_ptr)
print(f"mutex owner: {owner_task.comm.string_().decode()} "
f"pid={owner_task.pid.value_()}")
for frame in prog.stack_trace(owner_task):
print(f" {frame}")
```
### Stack traces
```python
# IMPORTANT: prog.stack_trace() takes a task_struct or PID, NOT a CPU number
# By task_struct pointer:
for frame in prog.stack_trace(task):
print(frame)
# By PID:
for frame in prog.stack_trace(pid_number):
print(frame)
```
### Jiffies time delta
```python
jiffies = prog["jiffies"].value_()
hz = 1000 # CONFIG_HZ, usually 1000 on x86 — verify with the kernel config
delta_jiffies = jiffies - pool.watchdog_ts.value_()
delta_seconds = delta_jiffies / hz
```
## INVESTIGATION PROCEDURE
### Phase 1: Is the workqueue pool stuck?
The dmesg says pool 22 (cpus=5, normal priority) is hung for ~57500s with
multiple pending work items. If a pool has pending work items that are not
being processed, the pool IS stuck. Do not dismiss pending items as "about
to be run" — at 57500s, anything pending is stuck.
Your goal in this phase is to determine WHY the pool is stuck: is it a
concurrency management state bug (nr_running wrong), a worker shortage
(no idle workers, can't create new ones), or something else?
**Step 1.1: Pool overview**
```python
cpu = 5
pool = per_cpu(prog["cpu_worker_pools"], cpu)[0]
print(f"Pool {pool.id.value_()} on CPU {pool.cpu.value_()}")
print(f" nr_running: {pool.nr_running.value_()}")
print(f" nr_workers: {pool.nr_workers.value_()}")
print(f" nr_idle: {pool.nr_idle.value_()}")
print(f" flags: 0x{pool.flags.value_():x}")
print(f" cpu_stall: {pool.cpu_stall.value_()}")
print(f" manager: {pool.manager}")
jiffies = prog["jiffies"].value_()
wts = pool.watchdog_ts.value_()
print(f" watchdog_ts: {wts} (jiffies={jiffies}, delta={jiffies - wts})")
print(f" worklist empty: {pool.worklist.next.value_() == pool.worklist.address_of_().value_()}")
```
**What to look for:**
- **nr_running**: If > 0 but no worker is actually executing on CPU, the
concurrency management thinks someone is running when nobody is. This
would prevent idle workers from being woken. Check every worker to verify
whether nr_running matches reality.
- **nr_idle**: If 0 and there's pending work, the pool has no reserve
workers. Check if a manager is active trying to create one — and if so,
what the manager is stuck on (likely a GFP_KERNEL allocation that won't
return).
- **nr_workers**: Compare to nr_idle to see how many are busy.
- **flags**: Check POOL_MANAGER_ACTIVE (0x2) — is someone trying to create
workers?
**Step 1.2: Enumerate ALL workers**
```python
WORKER_DIE = 0x2
WORKER_IDLE = 0x4
WORKER_PREP = 0x8
WORKER_CPU_INTENSIVE = 0x40
WORKER_UNBOUND = 0x80
for worker in list_for_each_entry("struct worker",
pool.workers.address_of_(), "node"):
task = worker.task
pid = task.pid.value_()
flags = worker.flags.value_()
state = []
if flags & WORKER_DIE: state.append("DIE")
if flags & WORKER_IDLE: state.append("IDLE")
if flags & WORKER_PREP: state.append("PREP")
if flags & WORKER_CPU_INTENSIVE: state.append("CPU_INTENSIVE")
if flags & WORKER_UNBOUND: state.append("UNBOUND")
if not state: state.append("RUNNING")
cur = worker.current_work
func_name = str(worker.current_func) if int(cur) else "(none)"
sleeping = worker.sleeping.value_()
last_active = worker.last_active.value_()
print(f" worker {worker.id.value_()}: pid={pid}, "
f"flags=0x{flags:x} [{','.join(state)}], "
f"sleeping={sleeping}, last_active={last_active}, "
f"current_func={func_name}")
# Stack trace for ALL non-idle workers:
if not (flags & WORKER_IDLE):
try:
print(f" Stack trace:")
for frame in prog.stack_trace(task):
print(f" {frame}")
except Exception as e:
print(f" (stack trace failed: {e})")
# Also check idle workers' task state — are they truly sleeping idle?
else:
tstate = task.__state.value_() if hasattr(task, '__state') else task.state.value_()
print(f" task state: {tstate}")
```
**What to look for:**
- For each non-idle worker: What is it doing? Is it sleeping on a lock?
Is it stuck in an allocation? Is it the manager trying to create workers?
- For idle workers: Are they in TASK_IDLE state as expected? If not,
something is wrong.
- Cross-check: Does the count of non-IDLE, non-PREP, non-CPU_INTENSIVE
workers match nr_running? If not, the concurrency management state is
inconsistent.
- Check worker.sleeping for non-idle workers: if sleeping==1, the worker
went through wq_worker_sleeping() and decremented nr_running. If all
non-idle workers have sleeping==1, nr_running should be 0.
**Step 1.3: Check pending work items**
```python
count = 0
for work in list_for_each_entry("struct work_struct",
pool.worklist.address_of_(), "entry"):
data = work.data.counter.value_()
func = str(work.func)
wq_name = "?"
if data & (1 << 2): # WORK_STRUCT_PWQ_BIT
pwq_addr = data & ~((1 << 8) - 1)
try:
pwq = Object(prog, "struct pool_workqueue", address=pwq_addr)
wq_name = pwq.wq.name.string_().decode()
except:
wq_name = f"(pwq@{pwq_addr:#x})"
print(f" [{count}] func={func}, wq={wq_name}")
count += 1
print(f"Total pending: {count}")
```
These are work items waiting to be executed. If there are multiple items and
idle workers exist, something is preventing the workers from picking them up.
Correlate with nr_running and worker states from Step 1.2.
**Step 1.4: Check pwq statistics**
Find pwqs associated with this pool and check started vs completed counts:
```python
# Iterate all workqueues and find pwqs for this pool
pool_id = pool.id.value_()
for wq in list_for_each_entry("struct workqueue_struct",
prog["workqueues"].address_of_(), "list"):
try:
pwq = per_cpu(wq.cpu_pwq, cpu)
if pwq.pool.id.value_() == pool_id:
started = pwq.stats[0].value_()
completed = pwq.stats[1].value_()
nr_active = pwq.nr_active.value_()
if started > 0 or nr_active > 0:
print(f" wq '{wq.name.string_().decode()}': "
f"started={started}, completed={completed}, "
f"in_flight={started-completed}, "
f"nr_active={nr_active}, "
f"max_active={wq.max_active.value_()}")
except:
pass # unbound workqueues don't have cpu_pwq
```
**Step 1.5: Determine the stall mechanism**
Based on the above evidence, determine WHICH of these scenarios applies:
**Scenario A — nr_running stuck > 0**: nr_running is positive but no worker
is actually executing on CPU. All non-idle workers have sleeping==1
(decremented nr_running) or are in PREP state, yet nr_running hasn't
reached 0. This prevents kick_pool() from waking idle workers. This would
be a concurrency management bug.
**Scenario B — No idle workers, manager stuck**: nr_idle is 0,
POOL_MANAGER_ACTIVE is set, and the manager worker is stuck trying to create
a new worker (blocked in GFP_KERNEL allocation or kthread_create). The pool
cannot make progress because there are no idle workers to wake and creating
new ones is blocked. Check the manager's stack trace to see where it's stuck.
If it's in the page allocator, this suggests system-wide memory pressure
where reclaim is not working.
**Scenario C — Workers all blocked on locks**: There are workers processing
work items, but every single one is sleeping on a mutex/lock. nr_running
correctly went to 0, idle workers were woken, but they too picked up work
items that immediately blocked. Eventually all workers are blocked and
no idle workers remain.
**Scenario D — Something else**: If none of the above, describe exactly what
you see and what doesn't add up.
### Phase 2: Investigate the broader stall
**IMPORTANT**: Do not assume the lock that reg_todo is waiting on is the
"root cause." The pool being stuck can CAUSE lock stalls elsewhere. Consider:
- If work item X is expected to release lock L, and work item X is pending
on a stuck pool, then anything waiting on lock L will appear deadlocked —
but the real cause is the pool stall, not a lock ordering bug.
- The cfg80211 reg_todo waiting on a mutex might be a VICTIM, not the cause.
The mutex holder might itself be waiting for something that depends on the
stuck pool.
**Step 2.1: Identify what the stuck worker(s) are waiting on**
For each non-idle worker found in Step 1.2, examine its stack trace. If it's
in `__mutex_lock`, `__rwsem_down_*`, `schedule_preempt_disabled`, or similar,
identify which lock:
```python
# For a worker stuck in __mutex_lock, try to extract the lock:
for frame in prog.stack_trace(stuck_task):
if "mutex_lock" in str(frame):
try:
lock = frame["lock"]
print(f" Mutex at: {lock}")
owner_val = lock.owner.counter.value_()
owner_ptr = owner_val & ~0x7
if owner_ptr:
owner = Object(prog, "struct task_struct",
address=owner_ptr)
print(f" Owner: {owner.comm.string_().decode()} "
f"pid={owner.pid.value_()}")
print(f" Owner stack:")
for f in prog.stack_trace(owner):
print(f" {f}")
else:
print(f" No owner (owner_val=0x{owner_val:x})")
except Exception as e:
print(f" (couldn't extract lock: {e})")
```
**Step 2.2: Follow the dependency chain**
For each lock owner found above:
1. Is the owner running, sleeping, or in D state?
2. If sleeping — what is it waiting on? Another lock? A completion? I/O?
3. If waiting on another lock — find THAT lock's owner and repeat.
4. At each step: is the waited-on resource something that depends on a
work item running? If so, check which pool/workqueue that work item
would run on — is THAT pool also stuck?
Continue until you find either:
- A cycle (A→B→C→A) — true deadlock
- A task waiting on something that depends on the stuck pool — the pool
stall is the root cause, the "deadlock" is a symptom
- A task waiting on something unrelated (I/O, userspace, etc.)
**Step 2.3: Check other pools and CPUs**
The stall might not be limited to pool 22. Check all CPU pools:
```python
import os
nr_cpus = int(prog["nr_cpu_ids"])
for cpu in range(nr_cpus):
pool = per_cpu(prog["cpu_worker_pools"], cpu)[0]
nr_r = pool.nr_running.value_()
nr_w = pool.nr_workers.value_()
nr_i = pool.nr_idle.value_()
wts = pool.watchdog_ts.value_()
delta = (jiffies - wts) / 1000
empty = pool.worklist.next.value_() == pool.worklist.address_of_().value_()
if not empty or delta > 30:
print(f"CPU {cpu}: pool {pool.id.value_()}, nr_running={nr_r}, "
f"nr_workers={nr_w}, nr_idle={nr_i}, "
f"hung={delta:.0f}s, worklist_empty={empty}")
```
**Step 2.4: Check for system-wide memory pressure**
If the pool stall involves a manager stuck in allocation:
```python
# Check memory state
from drgn.helpers.linux.percpu import per_cpu
try:
for node in range(int(prog["nr_online_nodes"])):
# Check per-node free pages
pass # Use /proc/meminfo equivalent via drgn
except:
pass
# Check if any workers are stuck in page allocation:
from drgn.helpers.linux.pid import for_each_task
alloc_stuck = []
for task in for_each_task(prog):
tstate = task.__state.value_() if hasattr(task, '__state') else task.state.value_()
if tstate != 0: # not TASK_RUNNING
try:
for frame in prog.stack_trace(task):
if "alloc_pages" in str(frame) or "__alloc_pages" in str(frame):
alloc_stuck.append(
f"{task.comm.string_().decode()} pid={task.pid.value_()}")
break
except:
pass
if alloc_stuck:
print(f"Tasks stuck in page allocation: {len(alloc_stuck)}")
for t in alloc_stuck[:20]:
print(f" {t}")
```
**Step 2.5: Check all D-state tasks for patterns**
```python
from drgn.helpers.linux.pid import for_each_task
d_state_tasks = []
for task in for_each_task(prog):
tstate = task.__state.value_() if hasattr(task, '__state') else task.state.value_()
if tstate == 2: # TASK_UNINTERRUPTIBLE
comm = task.comm.string_().decode()
pid = task.pid.value_()
try:
frames = [str(f) for f in prog.stack_trace(task)]
# Categorize by what they're stuck on
category = "unknown"
for f in frames:
if "mutex_lock" in f: category = "mutex"; break
if "rwsem" in f: category = "rwsem"; break
if "alloc_pages" in f: category = "alloc"; break
if "wait_for_completion" in f: category = "completion"; break
if "worker_thread" in f: category = "wq_idle"; break
d_state_tasks.append((category, comm, pid, frames[0] if frames else "?"))
except:
d_state_tasks.append(("error", comm, pid, "?"))
# Group by category
from collections import Counter
cats = Counter(cat for cat, _, _, _ in d_state_tasks)
print(f"D-state tasks by category: {dict(cats)}")
print(f"Total D-state tasks: {len(d_state_tasks)}")
for cat, comm, pid, top_frame in sorted(d_state_tasks)[:30]:
print(f" [{cat}] {comm} pid={pid}: {top_frame}")
```
## REPORTING
Present your findings in this order:
1. **Pool State** — Hard facts from Phase 1: nr_running, nr_idle,
nr_workers, pending work count, watchdog delta. For each worker: state,
current function, sleeping flag, stack trace. These are raw facts — state
them without interpretation first.
2. **Stall Mechanism** — Based on the pool state, which scenario (A/B/C/D)
applies and why. Cite specific values: "nr_running=1 but only worker is
in __mutex_lock with sleeping=1, so nr_running should be 0" or
"nr_idle=0, POOL_MANAGER_ACTIVE=1, manager pid=X stuck in __alloc_pages."
3. **Dependency Analysis** — The lock/wait chain from Phase 2. For each
link: who is waiting, on what, who holds it, what are they doing. Note
explicitly whether any link depends on a work item that would run on the
stuck pool.
4. **Root Cause** — What started the stall. This might be:
- A workqueue concurrency management bug (nr_running inconsistency)
- A worker creation failure (memory pressure preventing GFP_KERNEL allocs)
- A lock ordering issue in cfg80211/networking that caused workers to
all block
- Something else entirely
State this with evidence. If you cannot determine root cause with
certainty, say so and list the candidates with evidence for/against each.
5. **Cascade Effects** — What other subsystems are stalled as a consequence,
and through what mechanism (blocked on same lock, waiting for stuck work
item, etc.).
For EVERY claim, cite the specific drgn output. If you cannot support a
claim, explicitly say so and mark it as hypothesis.
## OUTPUT FORMAT
Write your complete findings as a Markdown file. The file should be
self-contained and suitable for posting as a reply to the bug report on
LKML. Structure it as follows:
```markdown
# Workqueue Lockup Analysis — CPU 5 Pool
## 1. Pool State
(raw facts: nr_running, nr_idle, nr_workers, flags, watchdog delta)
### Workers
(table or list of every worker: id, pid, state, current_func, sleeping,
stack trace for non-idle workers)
### Pending Work Items
(list of all pending work items on the worklist with function and workqueue)
### PWQ Statistics
(started/completed counts for active pwqs on this pool)
## 2. Stall Mechanism
(which scenario applies and WHY, with specific values cited as evidence)
## 3. Lock / Dependency Analysis
(the chain: who waits on what, who holds it, what are THEY waiting on —
with addresses and stack traces at each step. note whether any link depends
on a work item on the stuck pool.)
## 4. Other Pools and System-Wide State
(any other stuck pools, D-state task summary, memory pressure indicators)
## 5. Root Cause
(what started the stall, with evidence. or candidates if uncertain.)
## 6. Cascade Effects
(what else is broken as a consequence)
```
Save this file and tell the user where it is so they can attach it to their
reply.
^ permalink raw reply
* Re: [PATCH 03/61] ceph: Prefer IS_ERR_OR_NULL over manual NULL check
From: Viacheslav Dubeyko @ 2026-03-10 18:13 UTC (permalink / raw)
To: dm-devel@lists.linux.dev, phahn-oss@avm.de,
intel-wired-lan@lists.osuosl.org, linux-erofs@lists.ozlabs.org,
linux-security-module@vger.kernel.org, kvm@vger.kernel.org,
linux-sctp@vger.kernel.org, linux-pm@vger.kernel.org,
apparmor@lists.ubuntu.com, linux-ext4@vger.kernel.org,
amd-gfx@lists.freedesktop.org, linux-clk@vger.kernel.org,
linux-mips@vger.kernel.org, linux-media@vger.kernel.org,
netdev@vger.kernel.org, iommu@lists.linux.dev,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-usb@vger.kernel.org,
sched-ext@lists.linux.dev, linux-btrfs@vger.kernel.org,
linux-bluetooth@vger.kernel.org, linux-s390@vger.kernel.org,
samba-technical@lists.samba.org, intel-gfx@lists.freedesktop.org,
linux-trace-kernel@vger.kernel.org, ntfs3@lists.linux.dev,
linux-phy@lists.infradead.org, v9fs@lists.linux.dev,
ceph-devel@vger.kernel.org, tipc-discussion@lists.sourceforge.net,
linux-mtd@lists.infradead.org, linux-scsi@vger.kernel.org,
target-devel@vger.kernel.org, linux-gpio@vger.kernel.org,
cocci@inria.fr, linux-sh@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-cifs@vger.kernel.org, linux-modules@vger.kernel.org,
linux-sound@vger.kernel.org, bpf@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-input@vger.kernel.org,
linux-leds@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-hyperv@vger.kernel.org, linux-mm@kvack.org,
linux-nfs@vger.kernel.org, gfs2@lists.linux.dev,
linux-wireless@vger.kernel.org, linux-omap@vger.kernel.org
Cc: idryomov@gmail.com, Alex Markuze, slava@dubeyko.com
In-Reply-To: <20260310-b4-is_err_or_null-v1-3-bd63b656022d@avm.de>
On Tue, 2026-03-10 at 12:48 +0100, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Ilya Dryomov <idryomov@gmail.com>
> To: Alex Markuze <amarkuze@redhat.com>
> To: Viacheslav Dubeyko <slava@dubeyko.com>
> Cc: ceph-devel@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> fs/ceph/dir.c | 2 +-
> fs/ceph/snap.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
> index 86d7aa594ea99335af3e91a95c0a418fdc1b8a8a..934250748ae4fd4c148fd27bdf91175047c2877d 100644
> --- a/fs/ceph/dir.c
> +++ b/fs/ceph/dir.c
> @@ -889,7 +889,7 @@ int ceph_handle_notrace_create(struct inode *dir, struct dentry *dentry)
> {
> struct dentry *result = ceph_lookup(dir, dentry, 0);
>
> - if (result && !IS_ERR(result)) {
> + if (!IS_ERR_OR_NULL(result)) {
> /*
> * We created the item, then did a lookup, and found
> * it was already linked to another inode we already
> diff --git a/fs/ceph/snap.c b/fs/ceph/snap.c
> index 52b4c2684f922bfed39550311e793bfe3622cd26..528ad581be160713f91416115659e2dc6f259576 100644
> --- a/fs/ceph/snap.c
> +++ b/fs/ceph/snap.c
> @@ -902,7 +902,7 @@ int ceph_update_snap_trace(struct ceph_mds_client *mdsc,
> bad:
> err = -EIO;
> fail:
> - if (realm && !IS_ERR(realm))
> + if (!IS_ERR_OR_NULL(realm))
> ceph_put_snap_realm(mdsc, realm);
> if (first_realm)
> ceph_put_snap_realm(mdsc, first_realm);
Looks good.
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Thanks,
Slava.
^ permalink raw reply
* Re: [PATCH 00/61] treewide: Use IS_ERR_OR_NULL over manual NULL check - refactor
From: Kuan-Wei Chiu @ 2026-03-10 18:40 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
Hi Philipp,
On Tue, Mar 10, 2026 at 12:48:26PM +0100, Philipp Hahn wrote:
> While doing some static code analysis I stumbled over a common pattern,
> where IS_ERR() is combined with a NULL check. For that there is
> IS_ERR_OR_NULL().
>
> I've written a Coccinelle patch to find and patch those instances.
> The patches follow grouped by subsystem.
>
> Patches 55-58 may be dropped as they have a (minor?) semantic change:
> They use WARN_ON() or WARN_ON_ONCE(), but only in the IS_ERR() path, not
> for the NULL check. Iff it is okay to print the warning also for NULL,
> then the patches can be applied.
>
> While generating the patch set `checkpatch` complained about mixing
> [un]likely() with IS_ERR_OR_NULL(), which already uses likely()
> internally. I found and fixed several locations, where that combination
> has been used.
Thanks for the patchset. However, I think we need a explanation for why
switching to IS_ERR_OR_NULL() is an improvement over the existing code.
IMHO, the necessity of IS_ERR_OR_NULL() often highlights a confusing or
flawed API design. It usually implies that the caller is unsure whether
a failure results in an error pointer or a NULL pointer. Rather than
doing a treewide conversion of this pattern, I believe it would be much
more meaningful to review these instances case-by-case and fix the
underlying APIs or caller logic instead.
Additionally, a treewide refactoring like this has the practical
drawback of creating unnecessary merge conflicts when backporting to
stable trees.
Regards,
Kuan-Wei
^ permalink raw reply
* Re: 6.18.13 iwlwifi deadlock allocating cma while work-item is active.
From: Ben Greear @ 2026-03-10 19:18 UTC (permalink / raw)
To: Tejun Heo
Cc: Johannes Berg, linux-wireless, Miriam Rachel, linux-mm,
linux-kernel
In-Reply-To: <5b9b93df8774810a43fceb359906604b@kernel.org>
On 3/10/26 11:06, Tejun Heo wrote:
> Hello,
>
> Thanks for the detailed dump. One thing that doesn't look right is the
> number of pending work items on pool 22 (CPU 5). The pool reports 2 idle
> workers, yet there are 7+ work items sitting in the pending list across
> multiple workqueues. If the pool were making forward progress, those items
> would have been picked up by the idle workers. So, the pool itself seems to
> be stuck for some reason, and the cfg80211 mutex stall may be a consequence
> rather than the cause.
>
> Let's try using drgn on the crash dump. I'm attaching a prompt that you can
> feed to Claude (or any LLM with tool access to drgn). It contains workqueue
> internals documentation, drgn code snippets, and a systematic investigation
> procedure. The idea is:
>
> 1. Generate the crash dump when the deadlock is happening:
>
> echo c > /proc/sysrq-trigger
>
> 2. After the crash kernel boots, create the dump file:
>
> makedumpfile -c -d 31 /proc/vmcore /tmp/vmcore.dmp
>
> 3. Feed the attached prompt to Claude with drgn access to the dump. It
> should produce a Markdown report with its findings that you can post
> back here.
>
> This is a bit experimental, so let's see whether it works. Either way, the
> report should at least give us concrete data points to work with.
>
> Thanks.
Thanks for that. It will probably be a few days before I flip back to debugging
that lockup as I'm trying to get something ready for our internal release (using
kthread work-around).
While working on another bug, I found evidence (but not proof yet), that this code below
can be called multiple times for the same object. The bug I'm tracking is that this
may be the cause of list corruption (my debugging logs and work-arounds are in the method below).
But could this work-item (re)initialization also explain work-queue system going
weird? Just using kthreads, which 'fixes' the problem for me,
really shouldn't make a difference to the code below, so probably
it is not related?
void ieee80211_link_init(struct ieee80211_sub_if_data *sdata,
int link_id,
struct ieee80211_link_data *link,
struct ieee80211_bss_conf *link_conf)
{
struct ieee80211_local *local = sdata->local;
bool deflink = link_id < 0;
lockdep_assert_wiphy(local->hw.wiphy);
if (link_id < 0)
link_id = 0;
if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
struct ieee80211_sub_if_data *ap_bss;
struct ieee80211_bss_conf *ap_bss_conf;
ap_bss = container_of(sdata->bss,
struct ieee80211_sub_if_data, u.ap);
ap_bss_conf = sdata_dereference(ap_bss->vif.link_conf[link_id],
ap_bss);
memcpy(link_conf, ap_bss_conf, sizeof(*link_conf));
}
link->sdata = sdata;
link->link_id = link_id;
link->conf = link_conf;
link_conf->link_id = link_id;
link_conf->vif = &sdata->vif;
link->ap_power_level = IEEE80211_UNSET_POWER_LEVEL;
link->user_power_level = sdata->local->user_power_level;
link_conf->txpower = INT_MIN;
wiphy_work_init(&link->csa.finalize_work,
ieee80211_csa_finalize_work);
wiphy_work_init(&link->color_change_finalize_work,
ieee80211_color_change_finalize_work);
wiphy_delayed_work_init(&link->color_collision_detect_work,
ieee80211_color_collision_detection_work);
/* I see some sort of list corruption where links don't get removed from chanctx
* lists. I think if we are in a list while here, that could cause it. deflink
* appears to have chance of doing that. So, remove from list first if
* it is indeed in one.
*/
if (WARN_ON_ONCE((link->assigned_chanctx_list.next != LIST_POISON1)
&& (link->assigned_chanctx_list.next != link->assigned_chanctx_list.prev)
&& (link->assigned_chanctx_list.next))) {
sdata_err(sdata, "link-init: %d called while already in an assigned-chan-ctx list, clearing.\n",
link_id);
list_del(&link->assigned_chanctx_list);
}
if (WARN_ON_ONCE((link->reserved_chanctx_list.next != LIST_POISON1)
&& (link->reserved_chanctx_list.next != link->reserved_chanctx_list.prev)
&& (link->reserved_chanctx_list.next))) {
sdata_err(sdata, "link-init: %d called while already in a reserved-chan-ctx list, clearing.\n",
link_id);
list_del(&link->reserved_chanctx_list);
}
INIT_LIST_HEAD(&link->assigned_chanctx_list);
INIT_LIST_HEAD(&link->reserved_chanctx_list);
wiphy_delayed_work_init(&link->dfs_cac_timer_work,
ieee80211_dfs_cac_timer_work);
if (!deflink) {
switch (sdata->vif.type) {
case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_AP_VLAN:
ether_addr_copy(link_conf->addr,
sdata->wdev.links[link_id].addr);
link_conf->bssid = link_conf->addr;
WARN_ON(!(sdata->wdev.valid_links & BIT(link_id)));
break;
case NL80211_IFTYPE_STATION:
/* station sets the bssid in ieee80211_mgd_setup_link */
break;
default:
WARN_ON(1);
}
ieee80211_link_debugfs_add(link);
}
rcu_assign_pointer(sdata->vif.link_conf[link_id], link_conf);
rcu_assign_pointer(sdata->link[link_id], link);
}
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox