From: Jakub Sitnicki <jakub@cloudflare.com>
To: Zijing Yin <yzjaurora@gmail.com>
Cc: Stanislav Fomichev <sdf@fomichev.me>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Qingfang Deng <qingfang.deng@linux.dev>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] net: dev_addr_lists: don't WARN on GFP_ATOMIC kmalloc failure in netif_rx_mode_run
Date: Tue, 19 May 2026 13:22:33 +0200 [thread overview]
Message-ID: <878q9fod8m.fsf@cloudflare.com> (raw)
In-Reply-To: <20260519095557.3749407-1-yzjaurora@gmail.com> (Zijing Yin's message of "Tue, 19 May 2026 02:55:55 -0700")
On Tue, May 19, 2026 at 02:55 AM -07, Zijing Yin wrote:
> netif_rx_mode_run() fires netdev_WARN() when netif_addr_lists_snapshot()
> returns non-zero. The only path to a non-zero return is -ENOMEM from
> __hw_addr_create() failing its kmalloc(GFP_ATOMIC) -- syzkaller hits it
> via failslab, and it can also be reached under real memory pressure.
>
> This is the only allocator-failure site in this file that WARNs.
> __hw_addr_create() itself, and every other caller of it in this file
> (__hw_addr_add_ex(), dev_uc_add_excl(), dev_uc_add(), dev_mc_add(), ...)
> just propagate the -ENOMEM silently. GFP_ATOMIC is a may-fail allocator;
> callers are required to handle NULL, so a returned -ENOMEM here is an
> expected runtime condition, not an invariant violation.
>
> The miss is self-healing: any subsequent change to dev->uc / dev->mc
> (every dev_{uc,mc}_{add,del}, IFF_PROMISC flip, etc.) calls
> __dev_set_rx_mode() -> netif_rx_mode_queue(), which re-queues the device
> and retries the sync. The only cost of a failed attempt is one stale
> rx-mode window until the next update; nothing in the kernel relies on
> this attempt succeeding.
>
> Demote to net_err_ratelimited() so the condition stays observable in
> dmesg without tripping panic_on_warn.
>
> Reproducer (syzkaller .prog format with setup notes):
> https://pastebin.com/t7AQKx9v
>
> Fixes: 3554b4345d85 ("net: introduce ndo_set_rx_mode_async and netdev_rx_mode_work")
> Signed-off-by: Zijing Yin <yzjaurora@gmail.com>
> ---
> net/core/dev_addr_lists.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
> index d73fcb0c6..c6fdcac74 100644
> --- a/net/core/dev_addr_lists.c
> +++ b/net/core/dev_addr_lists.c
> @@ -1275,7 +1275,8 @@ static void netif_rx_mode_run(struct net_device *dev)
> err = netif_addr_lists_snapshot(dev, &uc_snap, &mc_snap,
> &uc_ref, &mc_ref);
> if (err) {
> - netdev_WARN(dev, "failed to sync uc/mc addresses\n");
> + net_err_ratelimited("%s: failed to sync uc/mc addresses\n",
> + netdev_name(dev));
> netif_addr_unlock_bh(dev);
> return;
> }
1) I'd go with net_warn_ratelimited() instead. The promoted message
level in syslog might cause operational pain, and as you say the
condition is self-healing. Seems unwarranted.
2) Since it has a Fixes tag, should probably be sumitted for 'net' tree.
3) Was this reported by syzbot? If so, there should also be Reported-by
and Closes tags.
next prev parent reply other threads:[~2026-05-19 11:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 9:55 [PATCH net-next] net: dev_addr_lists: don't WARN on GFP_ATOMIC kmalloc failure in netif_rx_mode_run Zijing Yin
2026-05-19 11:22 ` Jakub Sitnicki [this message]
2026-05-19 12:11 ` Zijing yin
2026-05-19 12:22 ` Jiayuan Chen
2026-05-19 12:26 ` Zijing yin
2026-05-19 22:54 ` Jakub Kicinski
2026-05-19 23:24 ` Stanislav Fomichev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878q9fod8m.fsf@cloudflare.com \
--to=jakub@cloudflare.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=qingfang.deng@linux.dev \
--cc=sdf@fomichev.me \
--cc=yzjaurora@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.