netdev - Re: [PATCH net-next] net: bridge: Lock before br_fdb

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 30 May 2018 12:42:15 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     petrm@...lanox.com
Cc:     bridge@...ts.linux-foundation.org, netdev@...r.kernel.org,
        stephen@...workplumber.org
Subject: Re: [PATCH net-next] net: bridge: Lock before br_fdb_find()

From: Petr Machata <petrm@...lanox.com>
Date: Mon, 28 May 2018 17:44:16 +0200

> Callers of br_fdb_find() need to hold the hash lock, which
> br_fdb_find_port() doesn't do. Add the missing lock/unlock
> pair.
> 
> Signed-off-by: Petr Machata <petrm@...lanox.com>

If all of the these uses of br_fdb_find_port() are safe, then it
should use the RCU fdb lookup variant.

So I basically agree with Stephen that this locking doesn't make any
sense.

The lock is needed when you are going to add or delete an FDB entry.

Here we are doing a lookup and returning a device pointer via the FDB
entry found in the lookup.

The RTNL assertion assures that the device returned won't disappear.

If the device can disappear, the spinlock added by this patch doesn't
change that at all.