linux-kernel - Re: [PATCH net-next v09 1/8] hinic3: Async Event Queue interfaces

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250717080229.1054761-1-gur.stavi@huawei.com>
Date: Thu, 17 Jul 2025 11:02:29 +0300
From: Gur Stavi <gur.stavi@...wei.com>
To: <kuba@...nel.org>
CC: <andrew+netdev@...n.ch>, <christophe.jaillet@...adoo.fr>,
	<corbet@....net>, <davem@...emloft.net>, <edumazet@...gle.com>,
	<fuguiming@...artners.com>, <gongfan1@...wei.com>, <guoxin09@...wei.com>,
	<gur.stavi@...wei.com>, <helgaas@...nel.org>, <horms@...nel.org>,
	<jdamato@...tly.com>, <lee@...ger.us>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <luosifu@...wei.com>,
	<meny.yossefi@...wei.com>, <mpe@...erman.id.au>, <netdev@...r.kernel.org>,
	<pabeni@...hat.com>, <przemyslaw.kitszel@...el.com>,
	<shenchenyang1@...ilicon.com>, <shijing34@...wei.com>, <sumang@...vell.com>,
	<vadim.fedorenko@...ux.dev>, <wulike1@...wei.com>, <zhoushuai28@...wei.com>,
	<zhuyikai1@...artners.com>
Subject: Re: [PATCH net-next v09 1/8] hinic3: Async Event Queue interfaces

On Tue, 15 Jul 2025 08:28:36 +0800 Fan Gong wrote:
> +/* Data provided to/by cmdq is arranged in structs with little endian fields but
> + * every dword (32bits) should be swapped since HW swaps it again when it
> + * copies it from/to host memory. This is a mandatory swap regardless of the
> + * CPU endianness.

> This comment makes no sense, FWIW. The device writes a byte steam
> to host memory. For what you're saying to make sense the device would
> have to intentionally switch the endian based on the host CPU.
> And if it could do that why wouldn't it do it in the opposite
> direction, avoiding the swap ? :/
>
> I suppose the device is always writing in be32 words, and you should
> be converting from be32.
>

Lets assume the following is a simplified PACKED cmdq struct:

struct some_cmdq {
	__le16 a;
	__le32 b;
	__le16 c;
};

Lets denote x0 as lsb of field x. x3 as msb of 32 bits field.

Byte stream in CPU memory is:
a0, a1, b0, b1, b2, b3, c0, c1

The HW expects the following byte stream:
b1, b0, a1, a0, c1, c0, b3 ,b2

A native struct would be:

struct some_cmdq {
	__be16 b_lo;
	__be16 a;
	__be16 c;
	__be16 b_hi;
}

It does not make sense from code readability perspective.
While this is a simplified example, there are similar problems in real cmdq
structs.
Also group of fields that makes sense (based on their names) for being
logically near each other become separated in "native" big endian arrangements.

This is a case where driver need to compensate for bad HW decisions.