[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250810182752.GM222315@ZenIV>
Date: Sun, 10 Aug 2025 19:27:52 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Ujwal Kundur <ujwal.kundur@...il.com>, g@...iv.linux.org.uk
Cc: allison.henderson@...cle.com, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
rds-devel@....oracle.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] rds: Fix endian annotations across various
assignments
On Sun, Aug 10, 2025 at 07:25:06PM +0100, Al Viro wrote:
> On Sun, Aug 10, 2025 at 06:47:05PM +0100, Al Viro wrote:
>
> > > switch (type) {
> > > case RDS_EXTHDR_NPATHS:
> > > conn->c_npaths = min_t(int, RDS_MPATH_WORKERS,
> > > - be16_to_cpu(buffer.rds_npaths));
> > > + (__force __u16)buffer.rds_npaths);
> >
> > No. It will break on little-endian. That's over-the-wire data you are
> > dealing with; it's *NOT* going to be host-endian. Fix the buggered
> > annotations instead.
>
> PS: be16_to_cpu() is not the same thing as a cast. On a big-endian box,
> a 16bit number 1000 (0x3e8) is stored as {3, 0xe8}; on a little-endian it's
> {3, 0xe8} instead; {0xe8, 3} means 59395 there (0xe8 * 256 + 3).
^^^^^^^^ ^^^^^^^^^
{0xe8, 3} {3, 0xe8}
Sorry, buggered editing.
Powered by blists - more mailing lists