linux-kernel - Re: [PATCH 4/6] can: esd_usb: Improved behavior on esd CAN_ERROR

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] [day] [month] [year] [list]

Message-ID: <ec95c96b761df49ae19ff333aad9857c5ec498e0.camel@esd.eu>
Date:   Tue, 12 Jul 2022 16:08:16 +0000
From:   Frank Jungclaus <Frank.Jungclaus@....eu>
To:     "mailhol.vincent@...adoo.fr" <mailhol.vincent@...adoo.fr>
CC:     Stefan Mätje <Stefan.Maetje@....eu>,
        "linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
        "mkl@...gutronix.de" <mkl@...gutronix.de>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "wg@...ndegger.com" <wg@...ndegger.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/6] can: esd_usb: Improved behavior on esd CAN_ERROR_EXT
 event (3)

On Tue, 2022-07-12 at 23:39 +0900, Vincent MAILHOL wrote:
> On Tue. 9 Jul. 2022 at 03:15, Frank Jungclaus <frank.jungclaus@....eu> wrote:
> > Started a rework initiated by Vincents remark about "You should not
> > report the greatest of txerr and rxerr but the one which actually
> > increased." Now setting CAN_ERR_CRTL_[RT]X_WARNING and
> > CAN_ERR_CRTL_[RT]X_PASSIVE depending on REC and TEC
> > 
> > Signed-off-by: Frank Jungclaus <frank.jungclaus@....eu>
> > ---
> >  drivers/net/can/usb/esd_usb.c | 16 +++++++++++-----
> >  1 file changed, 11 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/net/can/usb/esd_usb.c b/drivers/net/can/usb/esd_usb.c
> > index 0a402a23d7ac..588caba1453b 100644
> > --- a/drivers/net/can/usb/esd_usb.c
> > +++ b/drivers/net/can/usb/esd_usb.c
> > @@ -304,11 +304,17 @@ static void esd_usb_rx_event(struct esd_usb_net_priv *priv,
> >                         /* Store error in CAN protocol (location) in data[3] */
> >                         cf->data[3] = ecc & SJA1000_ECC_SEG;
> > 
> > -                       if (priv->can.state == CAN_STATE_ERROR_WARNING ||
> > -                           priv->can.state == CAN_STATE_ERROR_PASSIVE) {
> > -                               cf->data[1] = (txerr > rxerr) ?
> > -                                       CAN_ERR_CRTL_TX_PASSIVE :
> > -                                       CAN_ERR_CRTL_RX_PASSIVE;
> > +                       /* Store error status of CAN-controller in data[1] */
> > +                       if (priv->can.state == CAN_STATE_ERROR_WARNING) {
> > +                               if (txerr >= 96)
> > +                                       cf->data[1] |= CAN_ERR_CRTL_TX_WARNING;
> 
> As far as I understand, those flags should be set only when the
> threshold is *reached*:
> https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/can/error.h#L69
> 
> I don't think you should set it if the error state does not change.
> 
> Here, you probably want to compare the new value  with the previous
> one (stored in struct can_berr_counter) to decide whether or not the
> flags should be set.

Hi Vincent, I didn't interpret the comments given to data[1] in error.h
in that way (obviously). But after checking some other drivers, I see
they all seem to handle it the way you proposed it ...
So, I'll try to rework and resend patch 4/6, too.

Best regards, 
Frank

> 
> 
> > +                               if (rxerr >= 96)
> > +                                       cf->data[1] |= CAN_ERR_CRTL_RX_WARNING;
> > +                       } else if (priv->can.state == CAN_STATE_ERROR_PASSIVE) {
> > +                               if (txerr >= 128)
> > +                                       cf->data[1] |= CAN_ERR_CRTL_TX_PASSIVE;
> > +                               if (rxerr >= 128)
> > +                                       cf->data[1] |= CAN_ERR_CRTL_RX_PASSIVE;
> >                         }
> > 
> >                         cf->data[6] = txerr;
> > --
> > 2.25.1
> >