netdev - Re: Correct usage of dev_base

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 30 Nov 2020 13:41:23 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>,
        Eric Dumazet <edumazet@...gle.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Stephen Hemminger <stephen@...workplumber.org>,
        netdev <netdev@...r.kernel.org>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Jiri Benc <jbenc@...hat.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Andrew Lunn <andrew@...n.ch>
Subject: Re: Correct usage of dev_base_lock in 2020



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@....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