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

From: Al Viro <[email-masked]>
Date: Sun, 5 Aug 2018 16:28:11 +0100

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 <[email-masked]>
---
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 }
 };