From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [endianness bug?] cxgb4_next_header .match_val/.match_mask
 should be net-endian
Date: Sun, 5 Aug 2018 16:49:49 +0100
Message-ID: <20180805154949.GG15082@ZenIV.linux.org.uk>
References: <20180805152811.GF15082@ZenIV.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
To: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:46054 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726271AbeHERyw (ORCPT
        <rfc822;netdev@vger.kernel.org>); Sun, 5 Aug 2018 13:54:52 -0400
Content-Disposition: inline
In-Reply-To: <20180805152811.GF15082@ZenIV.linux.org.uk>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Sun, Aug 05, 2018 at 04:28:11PM +0100, Al Viro wrote:
> 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?

... and it looks like the same story with ->mask - it's compared to ->offmask,
which is __be16.  For little-endian hosts the values make sense (htons(0x0f00),
with offoff 0 and shift 6, i.e. "take the first two octets, treat them as
net-endian, clear everything except IHL bits and shift down by 6, which'd
yield IHL*4"), for big-endian they don't - you'd get TOS * 4 instead...