Messages in this thread | | | Date | Thu, 8 Dec 2022 11:37:49 +0100 | From | Sabrina Dubroca <> | Subject | Re: [PATCH net-next v3 1/2] macsec: add support for IFLA_MACSEC_OFFLOAD in macsec_changelink |
| |
2022-12-08, 06:53:18 +0000, Emeel Hakim wrote: > > > > -----Original Message----- > > From: Sabrina Dubroca <sd@queasysnail.net> > > Sent: Thursday, 8 December 2022 0:04 > > To: Emeel Hakim <ehakim@nvidia.com> > > Cc: linux-kernel@vger.kernel.org; Raed Salem <raeds@nvidia.com>; > > davem@davemloft.net; edumazet@google.com; kuba@kernel.org; > > pabeni@redhat.com; netdev@vger.kernel.org; atenart@kernel.org; jiri@resnulli.us > > Subject: Re: [PATCH net-next v3 1/2] macsec: add support for > > IFLA_MACSEC_OFFLOAD in macsec_changelink > > > > External email: Use caution opening links or attachments > > > > > > 2022-12-07, 15:52:15 +0000, Emeel Hakim wrote: > > > > > > > > > > -----Original Message----- > > > > From: Sabrina Dubroca <sd@queasysnail.net> > > > > Sent: Wednesday, 7 December 2022 17:46 > > > > To: Emeel Hakim <ehakim@nvidia.com> > > > > Cc: linux-kernel@vger.kernel.org; Raed Salem <raeds@nvidia.com>; > > > > davem@davemloft.net; edumazet@google.com; kuba@kernel.org; > > > > pabeni@redhat.com; netdev@vger.kernel.org; atenart@kernel.org; > > > > jiri@resnulli.us > > > > Subject: Re: [PATCH net-next v3 1/2] macsec: add support for > > > > IFLA_MACSEC_OFFLOAD in macsec_changelink > > > > > > > > External email: Use caution opening links or attachments > > > > > > > > > > > > 2022-12-07, 12:10:16 +0200, ehakim@nvidia.com wrote: > > > > [...] > > > > > +static int macsec_changelink_upd_offload(struct net_device *dev, > > > > > +struct nlattr *data[]) { > > > > > + enum macsec_offload offload; > > > > > + struct macsec_dev *macsec; > > > > > + > > > > > + macsec = macsec_priv(dev); > > > > > + offload = nla_get_u8(data[IFLA_MACSEC_OFFLOAD]); > > > > > > > > All those checks are also present in macsec_upd_offload, why not > > > > move them into macsec_update_offload as well? (and then you don't > > > > really need macsec_changelink_upd_offload anymore) > > > > > > > > > > Right, I thought about it , but I realized that those checks are done > > > before holding the lock in macsec_upd_offload and if I move them to > > > macsec_update_offload I will hold the lock for a longer time , I want to minimize > > the time of holding the lock. > > > > Those couple of tests are probably lost in the noise compared to what > > mdo_add_secy ends up doing. It also looks like a race condition between the > > "macsec->offload == offload" test in macsec_upd_offload (outside rtnl_lock) and > > updating macsec->offload via macsec_changelink is possible. (Currently we can > > only change it with macsec_upd_offload (called under genl_lock) so there's no issue > > until we add this patch) > > Ack, > so getting rid of macsec_changelink_upd_offload and moving the locking inside macsec_update_offload > should handle this issue
You mean moving rtnl_lock()/unlock inside macsec_update_offload? changelink is already under rtnl_lock. Just move the checks that you currently have in macsec_changelink_upd_offload into macsec_update_offload, and remove them from macsec_upd_offload.
> > > > > > > + if (macsec->offload == offload) > > > > > + return 0; > > > > > + > > > > > + /* Check if the offloading mode is supported by the underlying layers */ > > > > > + if (offload != MACSEC_OFFLOAD_OFF && > > > > > + !macsec_check_offload(offload, macsec)) > > > > > + return -EOPNOTSUPP; > > > > > + > > > > > + /* Check if the net device is busy. */ > > > > > + if (netif_running(dev)) > > > > > + return -EBUSY; > > > > > + > > > > > + return macsec_update_offload(macsec, offload); } > > > > > + > > > > > > > > -- > > > > Sabrina > > > > > > > -- > > Sabrina >
-- Sabrina
| |