Re: [PATCH v3 6/9] checksum: use csum_ip4_header() in udp.c and tcp.c

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 1 Mar 2024 23:23:41 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Fri, Mar 01, 2024 at 08:58:45AM +0100, Stefano Brivio wrote:
> > On Fri, 1 Mar 2024 10:10:52 +1100
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >   
> > > On Thu, Feb 29, 2024 at 05:24:06PM +0100, Stefano Brivio wrote:  
> > > > On Sat, 17 Feb 2024 16:07:22 +0100
> > > > Laurent Vivier <lvivier@redhat.com> wrote:
> > > >     
> > > > > +uint16_t csum_ip4_header(uint16_t tot_len, uint8_t protocol,
> > > > > +			 uint32_t saddr, uint32_t daddr)
> > > > >  {
> > > > > -	ip4h->check = 0;
> > > > > -	ip4h->check = csum(ip4h, (size_t)ip4h->ihl * 4, 0);
> > > > > +	uint32_t sum = L2_BUF_IP4_PSUM(protocol);    
> > > > 
> > > > Now that we use this macro, Coverity Scan realises that it's broken:
> > > > 
> > > > #define L2_BUF_IP4_PSUM(proto) ((uint32_t)htons_constant(0x4500) +     \
> > > > 				(uint32_t)htons_constant(0xff00 | (proto)))
> > > > 
> > > > ...but proto is eight (lower) bits, so this actually ignores 'proto'.    
> > > 
> > > Uh... how so?  
> > 
> > Oops, sorry, it's not broken, and this is a false positive due to the
> > fact that __bswap_constant_16() (which htons_constant() resolves to, on
> > little-endian) is defined, for example in glibc, as:
> > 
> > #define __bswap_constant_16(x) \
> >      ((((x) >> 8) & 0xff) | (((x) & 0xff) << 8))
> > 
> > and in this case the first term of the | resolves to a constant value,
> > 0xff, because 0xffxx >> 8 is 0xff for any value of xx.  
> 
> Right.  This really seems overzealous of coverity: it seems like any
> occasion where the compiler would constant fold could result in a
> similar warning.
> 
> > I couldn't think of a "solution", yet.  
> 
> Making it an inline function rather than a macro might be enough to
> convince Coverity.  Otherwise we could just mark it as a false
> positive in the Coverity web interface.

The inline function didn't help per se, but while trying it out (with a
number of variations on it) I realised that, Coverity being overzealous
or not... 'proto' isn't a constant, so we shouldn't use
__bswap_constant_16(), unless we want to define three constants for the
Layer-4 protocols we support.

Switched to htons() as it obviously ought to be, problem solved. I'll
post this as follow-up patch to Laurent's series.

-- 
Stefano