Re: [endianness bug?] cxgb4_next_header .match_val/.match_mask should be net-endian

[Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>]

On Sunday, August 08/05/18, 2018 at 20:58:11 +0530, Al Viro wrote:
> 	AFAICS, cxgb4_next_header() expects to find match_val/match_mask in 
> struct cxgb4_next_header stored as big-endian:
> 
>                         /* Found a possible candidate.  Find a key that
>                          * matches the corresponding offset, value, and
>                          * mask to jump to next header.
>                          */
>                         for (j = 0; j < cls->knode.sel->nkeys; j++) {
>                                 off = cls->knode.sel->keys[j].off;
>                                 val = cls->knode.sel->keys[j].val;
>                                 mask = cls->knode.sel->keys[j].mask;
> 
>                                 if (next[i].match_off == off &&
>                                     next[i].match_val == val &&
>                                     next[i].match_mask == mask) {
>                                         found = true;
>                                         break;
>                                 }
>                         }
> 
> Here ->keys[] is struct tc_u32_key and there mask and val are definitely
> __be32.  match_val and match_mask are never changed after initialization
> and they are set to:
> 
> * .match_off = 8, .match_val = 0x600, .match_mask = 0xFF00
> 	meant to check for IPV4.Protocol == TCP, i.e. octet at offset 9 being 6
> * .match_off = 8, .match_val = 0x1100, .match_mask = 0xFF00
> 	meant to check for IPV4.Protocol == UDP, i.e. octet at offset 9 being 0x11
> * .match_off = 4, .match_val = 0x60000, .match_mask = 0xFF0000
> 	IPV6.NextHeader == TCP, i.e. octet at offset 6 being 6
> * .match_off = 4, .match_val = 0x110000, .match_mask = 0xFF0000
> 	IPV6.NextHeader == UDP, i.e. octet at offset 6 being 0x11
> 
> On little-endian host those do yield the right values - e.g. 0x1100 is
> {0, 17, 0, 0}, etc.  On big-endian, though, these will end up checking
> in IPv4 case the octet at offset 10 (i.e. upper 16 bits of checksum) and for IPv6
> - the octet at offset 5 (i.e.  the lower 8 bits of payload length).
> 
> Unless I'm misreading that code, it needs the following to do the right
> thing both on l-e and b-e.  Comments?
> 
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h
> index a4b99edcc339..ec226b1cebf4 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h
> @@ -259,11 +259,11 @@ struct cxgb4_next_header {
>   */
>  static const struct cxgb4_next_header cxgb4_ipv4_jumps[] = {
>  	{ .offset = 0, .offoff = 0, .shift = 6, .mask = 0xF,
> -	  .match_off = 8, .match_val = 0x600, .match_mask = 0xFF00,
> -	  .jump = cxgb4_tcp_fields },
> +	  .match_off = 8, .match_val = htonl(6 << 16),
> +	  .match_mask = htonl(0xff<<16), .jump = cxgb4_tcp_fields },
>  	{ .offset = 0, .offoff = 0, .shift = 6, .mask = 0xF,
> -	  .match_off = 8, .match_val = 0x1100, .match_mask = 0xFF00,
> -	  .jump = cxgb4_udp_fields },
> +	  .match_off = 8, .match_val = htonl(17 << 16),
> +	  .match_mask = htonl(0xff<<16), .jump = cxgb4_udp_fields },
>  	{ .jump = NULL }
>  };
>  
> @@ -272,11 +272,11 @@ static const struct cxgb4_next_header cxgb4_ipv4_jumps[] = {
>   */
>  static const struct cxgb4_next_header cxgb4_ipv6_jumps[] = {
>  	{ .offset = 0x28, .offoff = 0, .shift = 0, .mask = 0,
> -	  .match_off = 4, .match_val = 0x60000, .match_mask = 0xFF0000,
> -	  .jump = cxgb4_tcp_fields },
> +	  .match_off = 4, .match_val = htonl(6 << 8),
> +	  .match_mask = htonl(0xff << 8), .jump = cxgb4_tcp_fields },
>  	{ .offset = 0x28, .offoff = 0, .shift = 0, .mask = 0,
> -	  .match_off = 4, .match_val = 0x110000, .match_mask = 0xFF0000,
> -	  .jump = cxgb4_udp_fields },
> +	  .match_off = 4, .match_val = htonl(17 << 8),
> +	  .match_mask = htonl(0xff << 8), .jump = cxgb4_udp_fields },
>  	{ .jump = NULL }
>  };
>  

Your observation is correct. The current logic is broken for
Big-Endian. Thanks for fixing it up Al!

As you've already found in the other email thread, ->mask also
needs to be fixed. Should be ".mask = htons(0xf << 8)".

Thanks,
Rahul