Messages in this thread |  | | Date | Tue, 15 Nov 2022 16:24:02 +0100 | From | netdev@kapio-te ... | Subject | Re: [PATCH v8 net-next 2/2] net: dsa: mv88e6xxx: mac-auth/MAB implementation |
| |
On 2022-11-15 16:12, Ido Schimmel wrote: > 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.
As I understand, dsa_port_to_bridge_port() needs to be called with the NL lock taken...
|  |