netdev - [RFC] weirdness in cxgb3_main.c:init_tp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20180805174649.GI15082@ZenIV.linux.org.uk>
Date:   Sun, 5 Aug 2018 18:46:49 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Santosh Raspatur <santosh@...lsio.com>
Cc:     netdev@...r.kernel.org
Subject: [RFC] weirdness in cxgb3_main.c:init_tp_parity()

        for (i = 0; i < 2048; i++) {
...
                req->l2t_idx = htonl(V_L2T_W_IDX(i));
...
	
in there is very odd; l2t_idx is a 16bit field, and
#define V_L2T_W_IDX(x) ((x) << S_L2T_W_IDX)
#define S_L2T_W_IDX    0

IOW, we are taking htonl(something in range 0..2047) and
shove it into 16bit field.  Which would, on a little-endian
host, be a fancy way of spelling 
                req->l2t_idx = 0;

What's the intended behaviour there?  I'm not familiar with
the hardware in question; this smells like a typoed
	req->l2t_idx = htons(...)
but how does the current code manage to work (i.e. does
anything even care about the value stored there)?  It's not
a big-endian-only driver, after all...