Thread (7 messages) 7 messages, 4 authors, 2018-05-30

Re: [PATCH net-next] net: bridge: Lock before br_fdb_find()

From: Petr Machata <hidden>
Date: 2018-05-30 22:03:26
Also in: bridge

David Miller [off-list ref] writes:
From: Petr Machata <redacted>
Date: Mon, 28 May 2018 17:44:16 +0200
quoted
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 <redacted>
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.
OK, I'll take another look at this.

Thanks,
Petr
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help