From: Moon Yeounsu <yyyynoom@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: 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
Subject: Re: [PATCH net-next v5] net: dlink: add support for reporting stats via `ethtool -S` and `ip -s -s link show`
Date: Tue, 1 Apr 2025 01:40:19 +0900 [thread overview]
Message-ID: <Z-rFcxj7XeiMHsz7@mythos-cloud> (raw)
In-Reply-To: <20241210191519.67a91a50@kernel.org>
First of all, I apologize for my late reply.
To be honest, I didn't fully understand the code I wrote.
The reason I initially decided to use `spin_lock_irqsave()` was that
most of the other stat-related code was using it.
So when I received your reply, I didn't understand why `spin_lock_bh()`
should be used. That's why I started reviewing interrupts and locks again.
As a result, my response got delayed. However, I believe I should take
full responsibility for the code I wrote.
I still don't fully understand interrupts and locks,
as the IRQ subsystem is vast and complex.
On Tue, Dec 10, 2024 at 07:15:19PM -0800, Jakub Kicinski wrote:
> On Mon, 9 Dec 2024 18:28:27 +0900 Moon Yeounsu wrote:
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&np->stats_lock, flags);
>
> I believe spin_lock_bh() is sufficient here, no need to save IRQ flags.
>
Anyway, base on what I have learned, I believe `spin_lock_irq()`
should be used in this context instead of `spin_lock_bh()`.
The reason is that the `get_stats()` function can be called from
an interrupt context (in the top-half).
If my understanding is correct, calling `spin_lock_bh()` in the
top-half may lead to a deadlock.
The calling sequence is as follows:
1. `rio_interrupt()` (registered via `request_irq()`)
2. `rio_error()`
3. `get_stats()`
> > + u64 collisions = np->single_collisions + np->multi_collisions;
> > + u64 tx_frames_abort = np->tx_frames_abort;
> > + u64 tx_carrier_errors = np->tx_carrier_sense_errors;
>
> Please don't mix code and variable declarations.
I'll fix it as well.
Thank you for pointing that out.
> --
> pw-bot: cr
If I am mistaken, please let me know.
Thank you for reviewing my patch!
next prev parent reply other threads:[~2025-03-31 16:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 9:28 [PATCH net-next v5] net: dlink: add support for reporting stats via `ethtool -S` and `ip -s -s link show` Moon Yeounsu
2024-12-11 3:15 ` Jakub Kicinski
2025-03-31 16:40 ` Moon Yeounsu [this message]
2025-03-31 21:25 ` Jakub Kicinski
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=Z-rFcxj7XeiMHsz7@mythos-cloud \
--to=yyyynoom@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--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.