Re: [PATCH net-next v9 2/6] net: airoha: Remove private net_device pointer in airoha_gdm_dev struct

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Potential deadlock in airoha_update_hw_stats() due to use of spin_lock() instead of spin_lock_bh().
--

commit d33fdec52e6f77bf6de4ab248729e1a868e78dc6
Author: Lorenzo Bianconi <lorenzo@kernel.org>

net: airoha: Remove private net_device pointer in airoha_gdm_dev struct

This commit removes the redundant net_device pointer from the
airoha_gdm_dev struct. The code now relies on the netdev_from_priv()
routine to retrieve the net_device pointer. This is a refactoring change
with no logical modifications.

> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 6574901ebd19b..57a16de0a2ec7 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential
deadlock in airoha_update_hw_stats():

drivers/net/ethernet/airoha/airoha_eth.c:airoha_update_hw_stats() {
	...
	spin_lock(&port->stats.lock);
	...
}

Does this code risk a deadlock? The ndo_get_stats64 callback
(airoha_dev_get_stats64) can be executed in softirq context, while this
lock is also acquired from process context (e.g., via ethtool) without
disabling softirqs.

If a softirq interrupts the process context reader holding the lock on the
same CPU, wouldn't it spin forever trying to acquire the same lock? Should
spin_lock_bh() be used here instead to prevent this?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603-airoha-eth-multi-serdes-v9-0-5d476bc2f426@kernel.org?part=2