netdev - Re: [PATCH net-next 18/29] can: pch_can: do not report txerr and rxerr during bus-off

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:   Thu, 21 Jul 2022 09:20:23 -0700
From:   Nathan Chancellor <nathan@...nel.org>
To:     Vincent MAILHOL <mailhol.vincent@...adoo.fr>
Cc:     Marc Kleine-Budde <mkl@...gutronix.de>, netdev@...r.kernel.org,
        davem@...emloft.net, kuba@...nel.org, linux-can@...r.kernel.org,
        kernel@...gutronix.de, llvm@...ts.linux.dev
Subject: Re: [PATCH net-next 18/29] can: pch_can: do not report txerr and
 rxerr during bus-off

On Fri, Jul 22, 2022 at 01:11:49AM +0900, Vincent MAILHOL wrote:
> On Fri. 22 Jul. 2022 at 00:49, Marc Kleine-Budde <mkl@...gutronix.de> wrote:
> > On 21.07.2022 08:27:06, Nathan Chancellor wrote:
> > > On Wed, Jul 20, 2022 at 10:10:23AM +0200, Marc Kleine-Budde wrote:
> > > > From: Vincent Mailhol <mailhol.vincent@...adoo.fr>
> > > >
> > > > During bus off, the error count is greater than 255 and can not fit in
> > > > a u8.
> > > >
> > > > Fixes: 0c78ab76a05c ("pch_can: Add setting TEC/REC statistics processing")
> > > > Link: https://lore.kernel.org/all/20220719143550.3681-2-mailhol.vincent@wanadoo.fr
> > > > Signed-off-by: Vincent Mailhol <mailhol.vincent@...adoo.fr>
> > > > Signed-off-by: Marc Kleine-Budde <mkl@...gutronix.de>
> > > > ---
> > > >  drivers/net/can/pch_can.c | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
> > > > index fde3ac516d26..497ef77340ea 100644
> > > > --- a/drivers/net/can/pch_can.c
> > > > +++ b/drivers/net/can/pch_can.c
> > > > @@ -496,6 +496,9 @@ static void pch_can_error(struct net_device *ndev, u32 status)
> > > >             cf->can_id |= CAN_ERR_BUSOFF;
> > > >             priv->can.can_stats.bus_off++;
> > > >             can_bus_off(ndev);
> > > > +   } else {
> > > > +           cf->data[6] = errc & PCH_TEC;
> > > > +           cf->data[7] = (errc & PCH_REC) >> 8;
> > > >     }
> > > >
> > > >     errc = ioread32(&priv->regs->errc);
> > > > @@ -556,9 +559,6 @@ static void pch_can_error(struct net_device *ndev, u32 status)
> > > >             break;
> > > >     }
> > > >
> > > > -   cf->data[6] = errc & PCH_TEC;
> > > > -   cf->data[7] = (errc & PCH_REC) >> 8;
> > > > -
> > > >     priv->can.state = state;
> > > >     netif_receive_skb(skb);
> > > >  }
> > > > --
> > > > 2.35.1
> > > >
> > > >
> > > >
> > >
> > > Apologies if this has been reported already, I didn't see anything on
> > > the mailing lists.
> > >
> > > This commit is now in -next as commit 3a5c7e4611dd ("can: pch_can: do
> > > not report txerr and rxerr during bus-off"), where it causes the
> > > following clang warning:
> > >
> > >   ../drivers/net/can/pch_can.c:501:17: error: variable 'errc' is uninitialized when used here [-Werror,-Wuninitialized]
> > >                   cf->data[6] = errc & PCH_TEC;
> > >                                 ^~~~
> > >   ../drivers/net/can/pch_can.c:484:10: note: initialize the variable 'errc' to silence this warning
> > >           u32 errc, lec;
> > >                   ^
> > >                    = 0
> > >   1 error generated.
> > >
> > > errc is initialized underneath this now, should it be hoisted or is
> > > there another fix?
> 
> Thanks for reporting and sorry for the bug.

No worries, it happens :)

> That said, I have one complaint: this type of warning is reported at
> W=2 *but* W=2 output is heavily polluted, mostly due to a false
> positive on linux/bits.h's GENMASK_INPUT_CHECK(). Under the current
> situation, the relevant warings become invisible with all the
> flooding.
> I tried to send a patch to silence a huge chunk of the W=2 spam in [1]
> but it got rejected. I am sorry but even with the best intent, I might
> repeat a similar mistake in the future. The W=2 is just not usable.
> 
> [1] https://lore.kernel.org/all/20220426161658.437466-1-mailhol.vincent@wanadoo.fr/

Yes, having -Wmaybe-uninitialized in W=2 is unfortunate because these
types of mistakes will continue to happen. I have been fighting this for
a while and so has Dan Carpenter, who started a thread about it a couple
of months ago but it doesn't seem like it really went anywhere:

https://lore.kernel.org/20220506091338.GE4031@kadam/

Cheers,
Nathan