[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260203201355.675b99cb@kernel.org>
Date: Tue, 3 Feb 2026 20:13:55 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: xuanzhuo@...ux.alibaba.com
Cc: lorenzo@...nel.org, andrew+netdev@...n.ch, pabeni@...hat.com,
vadim.fedorenko@...ux.dev, davem@...emloft.net, guwen@...ux.alibaba.com,
lulie@...ux.alibaba.com, hkallweit1@...il.com, edumazet@...gle.com,
lukas.bulwahn@...hat.com, andrew@...n.ch, dong100@...se.com,
dust.li@...ux.alibaba.com, netdev@...r.kernel.org
Subject: Re: [net-next,v25,6/6] eea: introduce callback for ndo_get_stats64
On Tue, 3 Feb 2026 20:08:41 -0800 Jakub Kicinski wrote:
> > +static void eea_stats(struct net_device *netdev, struct rtnl_link_stats64 *tot)
> > +{
> > + struct eea_net *enet = netdev_priv(netdev);
> > + u64 packets, bytes;
> > + u32 start;
> > + int i;
> > +
> > + spin_lock_bh(&enet->stats_lock);
>
> Can this cause a deadlock? The enet_bind_new_q_and_cfg() and
> eea_free_rxtx_q_mem() functions use spin_lock(&enet->stats_lock), but
> eea_stats() uses spin_lock_bh(&enet->stats_lock).
>
> If a thread holds stats_lock via spin_lock() (softirqs still enabled) and a
> softirq fires that calls eea_stats() through ndo_get_stats64, the
> spin_lock_bh() will attempt to acquire the already-held lock.
>
> Should all acquisition sites use spin_lock_bh()/spin_unlock_bh() for
> consistency?
AI suggestion is semi-right here, just remove the _bh()
I don't think we actually read stats from BH.
We read them under RCU, which is atomic context but not BH.
Powered by blists - more mailing lists