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).

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.

Fixes: 5e939544f9d2 ("mptcp: fix uninit-value in mptcp_established_options")
Suggested-by: Frank Ranner <frank.ranner@intel.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605312026.Srgsz7Tp-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202607031100.upQfRZTM-lkp@intel.com/
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 net/mptcp/options.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index 0ca60314d667..47d4a1b520d8 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -571,10 +571,7 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
 	bool ret = false;
 
 	/* Zero `use_ack` and `use_map` flags with one shot. */
-	BUILD_BUG_ON(sizeof_field(struct mptcp_ext, flags) != sizeof(u16));
-	BUILD_BUG_ON(!IS_ALIGNED(offsetof(struct mptcp_ext, flags),
-				 sizeof(u16)));
-	*(u16 *)&opts->ext_copy.flags = 0;
+	memset(&opts->ext_copy.flags, 0, sizeof(opts->ext_copy.flags));
 	opts->csum_reqd = READ_ONCE(msk->csum_enabled);
 	mpext = skb ? mptcp_get_ext(skb) : NULL;
 

---
base-commit: 44982139bcde9e34b46ddca0f91f3da9226ebf9a
change-id: 20260707-mptcp-opt-fix-config_aeabi-3d62f92ee7d7

Best regards,
--  
Matthieu Baerts (NGI0) <matttbe@kernel.org>

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.

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.

> 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.
 
      Arnd

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.

On Tue, 7 Jul 2026, 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).
>
> 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.
>
> Fixes: 5e939544f9d2 ("mptcp: fix uninit-value in mptcp_established_options")
> Suggested-by: Frank Ranner <frank.ranner@intel.com>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202605312026.Srgsz7Tp-lkp@intel.com/
> Closes: https://lore.kernel.org/oe-kbuild-all/202607031100.upQfRZTM-lkp@intel.com/
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> net/mptcp/options.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/net/mptcp/options.c b/net/mptcp/options.c
> index 0ca60314d667..47d4a1b520d8 100644
> --- a/net/mptcp/options.c
> +++ b/net/mptcp/options.c
> @@ -571,10 +571,7 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
> 	bool ret = false;
>
> 	/* Zero `use_ack` and `use_map` flags with one shot. */
> -	BUILD_BUG_ON(sizeof_field(struct mptcp_ext, flags) != sizeof(u16));
> -	BUILD_BUG_ON(!IS_ALIGNED(offsetof(struct mptcp_ext, flags),
> -				 sizeof(u16)));
> -	*(u16 *)&opts->ext_copy.flags = 0;
> +	memset(&opts->ext_copy.flags, 0, sizeof(opts->ext_copy.flags));
> 	opts->csum_reqd = READ_ONCE(msk->csum_enabled);
> 	mpext = skb ? mptcp_get_ext(skb) : NULL;

This change LGTM, thanks Matthieu

Reviewed-by: Mat Martineau <martineau@kernel.org>

Hi Mat,

On 17/07/2026 20:58, Mat Martineau wrote:
> On Tue, 7 Jul 2026, 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).

(...)
> This change LGTM, thanks Matthieu
> 
> Reviewed-by: Mat Martineau <martineau@kernel.org>

Thank you for the review, now in our tree:

New patches for t/upstream-net and t/upstream:
- 415e2360863e: mptcp: fix BUILD_BUG_ON on legacy ARM config
- Results: 8a872e28cb1f..6e75226ac108 (export-net)
- Results: 097e8a6a6720..4c2752580a3e (export)

Tests are now in progress:

- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/48a61d295983942723614a8001a83eb4ab615f2c/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/7566bcc19c2d8bdb40f5198185b347e85576fae8/checks

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Hi Matthieu,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/28884495747

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/b83e2c588655
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1123250


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)