[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180806121234.GA5560@chelsio.com>
Date: Mon, 6 Aug 2018 17:42:39 +0530
From: Rahul Lakkireddy <rahul.lakkireddy@...lsio.com>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
ganeshgr@...lsio.com, "David S. Miller" <davem@...emloft.net>
Subject: Re: [endianness bug?] cxgb4_next_header .match_val/.match_mask
should be net-endian
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@...iv.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
Powered by blists - more mailing lists