netdev - Re: [PATCH net] bnxt_en: replace reset with config timestamps

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 21 Sep 2022 14:33:14 -0700
From:   Michael Chan <michael.chan@...adcom.com>
To:     Vadim Fedorenko <vfedorenko@...ek.ru>
Cc:     Pavan Chebbi <pavan.chebbi@...adcom.com>,
        Netdev <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH net] bnxt_en: replace reset with config timestamps

On Tue, Sep 20, 2022 at 7:36 AM Michael Chan <michael.chan@...adcom.com> wrote:
>
> On Mon, Sep 19, 2022 at 11:39 AM Vadim Fedorenko <vfedorenko@...ek.ru> wrote:
> >
> > Any change to the hardware timestamps configuration triggers nic restart,
> > which breaks transmition and reception of network packets for a while.
> > But there is no need to fully restart the device because while configuring
> > hardware timestamps. The code for changing configuration runs after all
> > of the initialisation, when the NIC is actually up and running. This patch
> > changes the code that ioctl will only update configuration registers and
> > will not trigger carrier status change. Tested on BCM57504.
> >
> > Fixes: 11862689e8f1 ("bnxt_en: Configure ptp filters during bnxt open")
> > Cc: Richard Cochran <richardcochran@...il.com>
> > Signed-off-by: Vadim Fedorenko <vfedorenko@...ek.ru>
> > ---
> >  drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c | 6 ++----
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
> > index 8e316367f6ce..36e9148468b5 100644
> > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
> > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
> > @@ -505,10 +505,8 @@ static int bnxt_hwrm_ptp_cfg(struct bnxt *bp)
> >         ptp->tstamp_filters = flags;
> >
> >         if (netif_running(bp->dev)) {
> > -               rc = bnxt_close_nic(bp, false, false);
> > -               if (!rc)
> > -                       rc = bnxt_open_nic(bp, false, false);
> > -               if (!rc && !ptp->tstamp_filters)
> > +               bnxt_ptp_cfg_tstamp_filters(bp);
> > +               if (!ptp->tstamp_filters)
>
> Closing and opening is the correct sequence, but this might work too.
> Please give us a day to review this.  Thanks.

We have internally discussed this issue in great detail.  If the user
is changing the ALL_RX setting (enabling it or disabling it), just
calling bnxt_ptp_cfg_tstamp_filters() is not sufficient.  The reason
is that there is no synchronization after we send the new setting to
the FW.  We don't know when valid timestamps will start showing up in
the RX completion ring after turning on ALL_RX.  That's why we need to
close and open.  After open, all RX packets are guaranteed to have
valid timestamps.

So what we can do is to detect any changes to ALL_RX setting.  If
ALL_RX is not changing, we can just do what this patch is doing.  If
ALL_RX is changing, we can do something less intrusive than
close/open.  We can just shutdown RX and restart RX.  This way we
don't have to toggle carrier and cause a bigger disruption.

My colleague Pavan will take a few days to work on this.  Thanks.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4209 bytes)