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  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:   Wed, 9 Dec 2020 00:03:56 +0000
From:   Vladimir Oltean <>
To:     Jakub Kicinski <>
CC:     "David S . Miller" <>,
        "" <>,
        Andrew Lunn <>,
        Florian Fainelli <>,
        Paul Gortmaker <>,
        Pablo Neira Ayuso <>,
        Jiri Benc <>,
        Cong Wang <>,
        Jamal Hadi Salim <>,
        Stephen Hemminger <>,
        Eric Dumazet <>,
        George McCollister <>,
        Oleksij Rempel <>,
        Jay Vosburgh <>,
        Veaceslav Falico <>,
        Andy Gospodarek <>
Subject: Re: [RFC PATCH net-next 05/13] net: bonding: hold the netdev lists
 lock when retrieving device statistics

On Tue, Dec 08, 2020 at 03:57:44PM -0800, Jakub Kicinski wrote:
> On Mon, 7 Dec 2020 01:00:40 +0000 Vladimir Oltean wrote:
> > - ensuring through convention that user space always takes
> >   net->netdev_lists_lock when calling dev_get_stats, and documenting
> >   that, and therefore making it unnecessary to lock in bonding.
> This seems like the better option to me. Makes the locking rules pretty
> clear.

It is non-obvious to me that top-level callers of dev_get_stats should
hold a lock as specific as the one protecting the lists of network
interfaces. In the vast majority of implementations of dev_get_stats,
that lock would not actually protect anything, which would lead into
just one more lock that is used for more than it should be. In my tree I
had actually already switched over to mutex_lock_nested. Nonetheless, I
am still open if you want to make the case that simplicity should prevail
over specificity. But in that case, maybe we should just keep on using
the RTNL mutex.

Powered by blists - more mailing lists