netdev - Re: [PATCH net-next 3/3] eth: bnxt: handle invalid Tx completions more gracefully

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]

Message-ID: <5b722084c6031009f845e6af8b438d49b9ea7dc1.camel@redhat.com>
Date: Wed, 12 Jul 2023 08:50:06 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com, 
	michael.chan@...adcom.com
Subject: Re: [PATCH net-next 3/3] eth: bnxt: handle invalid Tx completions
 more gracefully

On Tue, 2023-07-11 at 18:19 -0700, Jakub Kicinski wrote:
> On Tue, 11 Jul 2023 12:10:28 +0200 Paolo Abeni wrote:
> > On Mon, 2023-07-10 at 13:56 -0700, Jakub Kicinski wrote:
> > > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
> > > index 080e73496066..08ce9046bfd2 100644
> > > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
> > > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
> > > @@ -1008,6 +1008,7 @@ struct bnxt_napi {
> > >  					  int);
> > >  	int			tx_pkts;
> > >  	u8			events;
> > > +	u8			tx_fault:1;  
> > 
> > Since there are still a few holes avail, I would use a plain u8 (or
> > bool) to help the compiler emit better code.
> 
> Is that still true or was it only true for old compilers?
> With gcc version 13.1.1 20230614 :
> 
> $ cat /tmp/t.c 
> #include <strings.h>
> 
> struct some {
>     void (*f)(void);
>     unsigned char b;
> #ifdef BLA
>     _Bool a;
> #else
>     unsigned char a:1;
> #endif
> };
> 
> int bla(struct some *s)
> {
>     if (s->a)
>         s->f();
>     return 0;
> }
> 
> $ gcc -W -Wall -O2  /tmp/t.c -o /tmp/t -c
> $ objdump -S /tmp/t > /tmp/a
> $ gcc -DBLA -W -Wall -O2  /tmp/t.c -o /tmp/t -c
> $ objdump -S /tmp/t > /tmp/b
> $ diff /tmp/a /tmp/b
> 8c8
> <    0:	f6 47 09 01          	testb  $0x1,0x9(%rdi)
> ---
> >    0:	80 7f 09 00          	cmpb   $0x0,0x9(%rdi)
> 
> $ gcc -V
> 
> Shouldn't matter, right?

Surely not a big deal. But some users (possibly most of them!) have
older compiler. Including an assignment in the test code, I get this
additional difference:

-   c:	80 4b 09 01          	orb    $0x1,0x9(%rbx)
+   c:	c6 43 09 01          	movb   $0x1,0x9(%rbx)

with the bitfield using the 'or' operation. Not a big deal, but the
other option is slightly better ;)

Cheers,

Paolo