From: Jakub Kicinski <kuba@kernel.org>
To: Gui-Dong Han <hanguidong02@gmail.com>
Cc: Chris Snook <chris.snook@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
baijiaju1990@gmail.com
Subject: Re: [PATCH] net: atheros: atl1e: use atomic functions with memory barriers for next_to_clean
Date: Mon, 27 Apr 2026 17:59:30 -0700 [thread overview]
Message-ID: <20260427175930.3c170c98@kernel.org> (raw)
In-Reply-To: <20260422093717.893646-1-hanguidong02@gmail.com>
On Wed, 22 Apr 2026 17:37:17 +0800 Gui-Dong Han wrote:
> Found by auditing atomic operations used for synchronization.
> A similar fix can be found in 6df8e84aa6b5.
>
> Do not change atl1e_init_ring_ptrs(). Its atomic_set() runs during
> bring-up before NAPI and interrupts are enabled, so it is not a runtime
> publication point between Tx cleanup and Tx submission.
>
> In my opinion, implementing ad-hoc lockless algorithms directly within
> individual drivers is highly error-prone. To avoid these subtle memory
> ordering and barrier bugs, drivers should rely on established, well-tested
> kernel libraries like kfifo to handle this type of concurrency.
I don't think this is sufficient, we can still race stop vs wake.
Please convert the driver to use netif_txq_maybe_stop() and friends.
--
pw-bot: cr
prev parent reply other threads:[~2026-04-28 0:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 9:37 [PATCH] net: atheros: atl1e: use atomic functions with memory barriers for next_to_clean Gui-Dong Han
2026-04-28 0:59 ` Jakub Kicinski [this message]
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=20260427175930.3c170c98@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=baijiaju1990@gmail.com \
--cc=chris.snook@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hanguidong02@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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.