From: Matthieu Baerts <matttbe@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>, MPTCP Linux <mptcp@lists.linux.dev>
Cc: Frank Ranner <frank.ranner@intel.com>, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH mptcp-net] mptcp: fix BUILD_BUG_ON on legacy ARM config
Date: Fri, 24 Jul 2026 10:25:24 +0200 [thread overview]
Message-ID: <9ff166c8-d045-4922-ad9a-c658a71e842d@kernel.org> (raw)
In-Reply-To: <ceb3b719-0a4c-4998-9a14-1eac1d574bb2@app.fastmail.com>
Hi Arnd,
Thank you for your review!
On 24/07/2026 09:57, Arnd Bergmann wrote:
> On Tue, Jul 7, 2026, at 18:48, Matthieu Baerts (NGI0) wrote:
>> The 0-day bot managed to find kernel configs that cause build failures,
>> e.g. when using the StrongARM SA1100 target (ARMv4).
>>
>> On such legacy ARM architecture, all structures are apparently aligned
>> to 32 bits, causing build issue here. Indeed, on such architecture,
>> 'flags' size is not equivalent to sizeof(u16) as expected, but to
>> sizeof(u32).
>
> I just saw the patch get merged upstream and wanted to clarify that
> this is ARM OABI (CONFIG_AEABI=n), which is technically unrelated
> to the CPU type. It has a lot of problems and should hopefully
> go away soon.
Fingers crossed!
> While I'm testing randconfig builds on Arm all the time, I specifically
> don't test OABI kernels.
>
> I had to check that this isn't actually ABI or wire protocol though,
> otherwise dropping the BUILD_BUG_ON() would be hiding bigger problems.
Thank you for having checked!
>> Instead, use memset(). It was not used before to ensure a simple clear
>> operation was used by the compiler. But at the end, it shouldn't matter,
>> and the compiler should optimise this to the same operation with or
>> without memset() when -O above 0 is used. So let's switch to memset() to
>> fix this issue, and reduce this complexity.
>
> The optimization will not be used on architectures that build
> with -ffreestanding (apparently m68k, mips, sh, i386). We probably
> don't care about performance on those or we would have changed
> that already.
Good point, I didn't know about that. Indeed, I don't think we need to
care about them in this case here.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
prev parent reply other threads:[~2026-07-24 8:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 16:48 [PATCH mptcp-net] mptcp: fix BUILD_BUG_ON on legacy ARM config Matthieu Baerts (NGI0)
2026-07-07 17:51 ` MPTCP CI
2026-07-17 18:58 ` Mat Martineau
2026-07-21 16:43 ` Matthieu Baerts
2026-07-24 7:57 ` Arnd Bergmann
2026-07-24 8:25 ` Matthieu Baerts [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ff166c8-d045-4922-ad9a-c658a71e842d@kernel.org \
--to=matttbe@kernel.org \
--cc=arnd@arndb.de \
--cc=frank.ranner@intel.com \
--cc=lkp@intel.com \
--cc=mptcp@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox