Messages in this thread |  | | Date | Tue, 15 Nov 2022 17:12:58 +0200 | From | Ido Schimmel <> | Subject | Re: [PATCH v8 net-next 2/2] net: dsa: mv88e6xxx: mac-auth/MAB implementation |
| |
On Tue, Nov 15, 2022 at 11:36:38AM +0100, netdev@kapio-technology.com wrote: > On 2022-11-15 10:58, Ido Schimmel wrote: > > On Sat, Nov 12, 2022 at 09:37:48PM +0100, Hans J. Schultz wrote: > > > diff --git a/drivers/net/dsa/mv88e6xxx/global1_atu.c > > > b/drivers/net/dsa/mv88e6xxx/global1_atu.c > > > index 8a874b6fc8e1..0a57f4e7dd46 100644 > > > --- a/drivers/net/dsa/mv88e6xxx/global1_atu.c > > > +++ b/drivers/net/dsa/mv88e6xxx/global1_atu.c > > > @@ -12,6 +12,7 @@ > > > > > > #include "chip.h" > > > #include "global1.h" > > > +#include "switchdev.h" > > > > > > /* Offset 0x01: ATU FID Register */ > > > > > > @@ -426,6 +427,8 @@ static irqreturn_t > > > mv88e6xxx_g1_atu_prob_irq_thread_fn(int irq, void *dev_id) > > > if (err) > > > goto out; > > > > > > + mv88e6xxx_reg_unlock(chip); > > > > Why? At minimum such a change needs to be explained in the commit > > message and probably split to a separate preparatory patch, assuming the > > change is actually required. > > This was a change done long time ago related to that the violation handle > function takes the NL lock, > which could lead to a double-lock deadlock afair if the chip lock is taken > throughout the handler.
Why do you need to take RTNL lock? br_switchdev_event() which receives the 'SWITCHDEV_FDB_ADD_TO_BRIDGE' event has this comment: "/* called with RTNL or RCU */" And it's using br_port_get_rtnl_rcu(), so looks like RCU is enough.
|  |