Re: Correct usage of dev_base_lock in 2020

Florian Fainelli
2020-11-30T21:42:22Z

On 11/30/2020 11:32 AM, Vladimir Oltean wrote:
> -----------------------------[cut here]-----------------------------
> From 93ffc25f30849aaf89e50e58d32b0b047831f94d Mon Sep 17 00:00:00 2001
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> Date: Mon, 30 Nov 2020 02:49:25 +0200
> Subject: [PATCH] parisc/led: retrieve device statistics under RTNL, not RCU
>
> In the effort of making .ndo_get_stats64 be able to sleep, we need to
> ensure the callers of dev_get_stats do not use atomic context.
>
> The LED driver for HP-PARISC workstations uses a workqueue to
> periodically check for updates in network interface statistics, and
> flicker when those have changed (i.e. there has been activity on the
> line). Honestly that is a strange idea even when protected by RCU, but
> now, the dev_get_stats call can sleep, and iterating through the list of
> network interfaces still needs to ensure the integrity of list of
> network interfaces. So that leaves us only one locking option given the
> current design of the network stack, and that is the RTNL mutex. In the
> future we might be able to make this a little bit less expensive by
> creating a separate mutex for the list of network interfaces.

We have a netdev LED trigger under drivers/leds/trigger/ledtrig-netdev.c
that appears to be nicely duplicating this LED driver.
--
Florian