[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240211161212.GL22081@brightrain.aerifal.cx>
Date: Sun, 11 Feb 2024 11:12:13 -0500
From: Rich Felker <dalias@...c.org>
To: "D. Jeff Dionne" <djeffdionne@...il.com>
Cc: Guenter Roeck <linux@...ck-us.net>,
John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
linux-sh@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Problems with csum_partial with misaligned buffers on sh4
platform
On Sun, Feb 11, 2024 at 12:41:16PM +0900, D. Jeff Dionne wrote:
> I remember there being problems with alignment on SH targets in the
> network stack. IIRC, wireguard triggered it in actual use, seems to
> me it had to do with skb alignment.
>
> Rich Felker may remember more, but I don’t think we implemented a
> (complete) solution.
What I recall was that some of the tunneling encapsulation code
ultimately did its zerocopy by arranging for either the inner or outer
headers to be misaligned (due to the historical badness of ethernet),
and thereby blowing up on archs without misaligned access support
(ours read/wrote bogus data, probably ignoring the low address bits or
something, on misaligned addresses). We never solved it; the code that
later worked was doing the encapsulatio in userspace without the
kernel's misaligned zerocopy stuff.
The right solution would be to make the affected accesses happen
through custom int16/int32 types with attribute packed applied to
them, so that on archs with misaligned access, the code would not
change at all, but on archs without it, the codegen would do
everything byte-by-byte and reassemble. But this would probably be an
invasive change that would make the maintainers of the network stack
unhappy...
Rich
Powered by blists - more mailing lists