From: Al Viro <viro@ZenIV.linux.org.uk>
To: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Cc: netdev@vger.kernel.org,
Hariprasad Shenai <hariprasad@chelsio.com>,
"David S. Miller" <davem@davemloft.net>
Subject: [endianness bug?] cxgb4_next_header .match_val/.match_mask should be net-endian
Date: Sun, 5 Aug 2018 16:28:11 +0100 [thread overview]
Message-ID: <20180805152811.GF15082@ZenIV.linux.org.uk> (raw)
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 }
};
next reply other threads:[~2018-08-05 17:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-05 15:28 Al Viro [this message]
2018-08-05 15:49 ` [endianness bug?] cxgb4_next_header .match_val/.match_mask should be net-endian Al Viro
2018-08-06 12:12 ` Rahul Lakkireddy
2018-08-06 19:51 ` kbuild test robot
2018-08-06 21:08 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180805152811.GF15082@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=davem@davemloft.net \
--cc=hariprasad@chelsio.com \
--cc=netdev@vger.kernel.org \
--cc=rahul.lakkireddy@chelsio.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).