public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] net: ipv6: fix ARM64 alignment fault in fib_multipath_hash_from_keys()
@ 2026-02-26 11:17 Yung Chih Su
  2026-02-26 12:02 ` Eric Dumazet
  2026-02-27  1:14 ` Jakub Kicinski
  0 siblings, 2 replies; 7+ messages in thread
From: Yung Chih Su @ 2026-02-26 11:17 UTC (permalink / raw)
  To: davem, dsahern, edumazet, kuba, pabeni, horms, nathan,
	nick.desaulniers+lkml, morbo, justinstitt
  Cc: netdev, linux-kernel, llvm, Yung Chih Su

struct sysctl_fib_multipath_hash_seed contains two u32 fields (user_seed
and mp_seed), making it an 8-byte structure with a 4-byte alignment requirement.

In fib_multipath_hash_from_keys(), the code evaluates the entire struct
atomically via READ_ONCE():

mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed;
While this silently works on GCC by falling back to unaligned regular loads
(e.g., LDR/LDUR) which the ARM64 kernel tolerates, it causes a fatal kernel
panic when compiled with Clang and LTO enabled.

Commit e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when
CONFIG_LTO=y") strengthens READ_ONCE() to use Load-Acquire instructions
(ldar / ldapr) to prevent compiler reordering bugs under Clang LTO.

Since the macro evaluates the full 8-byte struct, Clang emits a 64-bit
ldar instruction. ARM64 architecture strictly requires ldar to be
naturally aligned. Executing a 64-bit ldar on a 4-byte aligned address
(e.g., ending in 0xEC) triggers a strict Alignment Fault (FSC = 0x21).

Fix this by moving the READ_ONCE() directly to the specific u32 member:

mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed);
This instructs the compiler to emit a 32-bit load (ldar Wn or ldr Wn),
which perfectly satisfies the 4-byte alignment requirement and resolves
the crash.

Fixes: [4ee2a8cace3fb9a34aea6a56426f89d26dd514f3] ("net: ipv4: Add a sysctl to set multipath hash seed")
Signed-off-by: Yung Chih Su <yuuchihsu@gmail.com>
---
 include/net/ip_fib.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index b4495c38e0a0..318593743b6e 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -559,7 +559,7 @@ static inline u32 fib_multipath_hash_from_keys(const struct net *net,
 	siphash_aligned_key_t hash_key;
 	u32 mp_seed;
 
-	mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed;
+	mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed);
 	fib_multipath_hash_construct_key(&hash_key, mp_seed);
 
 	return flow_hash_from_keys_seed(keys, &hash_key);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] net: ipv6: fix ARM64 alignment fault in fib_multipath_hash_from_keys()
  2026-02-26 11:17 [PATCH] net: ipv6: fix ARM64 alignment fault in fib_multipath_hash_from_keys() Yung Chih Su
@ 2026-02-26 12:02 ` Eric Dumazet
  2026-02-26 14:49   ` Sam Su
  2026-02-27  1:14 ` Jakub Kicinski
  1 sibling, 1 reply; 7+ messages in thread
From: Eric Dumazet @ 2026-02-26 12:02 UTC (permalink / raw)
  To: Yung Chih Su
  Cc: davem, dsahern, kuba, pabeni, horms, nathan,
	nick.desaulniers+lkml, morbo, justinstitt, netdev, linux-kernel,
	llvm

On Thu, Feb 26, 2026 at 12:18 PM Yung Chih Su <yuuchihsu@gmail.com> wrote:
>
> struct sysctl_fib_multipath_hash_seed contains two u32 fields (user_seed
> and mp_seed), making it an 8-byte structure with a 4-byte alignment requirement.
>
> In fib_multipath_hash_from_keys(), the code evaluates the entire struct
> atomically via READ_ONCE():
>
> mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed;
> While this silently works on GCC by falling back to unaligned regular loads
> (e.g., LDR/LDUR) which the ARM64 kernel tolerates, it causes a fatal kernel
> panic when compiled with Clang and LTO enabled.
>
> Commit e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when
> CONFIG_LTO=y") strengthens READ_ONCE() to use Load-Acquire instructions
> (ldar / ldapr) to prevent compiler reordering bugs under Clang LTO.
>
> Since the macro evaluates the full 8-byte struct, Clang emits a 64-bit
> ldar instruction. ARM64 architecture strictly requires ldar to be
> naturally aligned. Executing a 64-bit ldar on a 4-byte aligned address
> (e.g., ending in 0xEC) triggers a strict Alignment Fault (FSC = 0x21).
>
> Fix this by moving the READ_ONCE() directly to the specific u32 member:
>
> mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed);
> This instructs the compiler to emit a 32-bit load (ldar Wn or ldr Wn),
> which perfectly satisfies the 4-byte alignment requirement and resolves
> the crash.
>
> Fixes: [4ee2a8cace3fb9a34aea6a56426f89d26dd514f3] ("net: ipv4: Add a sysctl to set multipath hash seed")
> Signed-off-by: Yung Chih Su <yuuchihsu@gmail.com>
> ---
>  include/net/ip_fib.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
> index b4495c38e0a0..318593743b6e 100644
> --- a/include/net/ip_fib.h
> +++ b/include/net/ip_fib.h
> @@ -559,7 +559,7 @@ static inline u32 fib_multipath_hash_from_keys(const struct net *net,
>         siphash_aligned_key_t hash_key;
>         u32 mp_seed;
>
> -       mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed;
> +       mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed);
>         fib_multipath_hash_construct_key(&hash_key, mp_seed);
>
>         return flow_hash_from_keys_seed(keys, &hash_key);

What about proc_fib_multipath_hash_set_seed() ?

It has :

WRITE_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed, new);

Which is IMO strange, regardless of ARM64 clang and whats not.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] net: ipv6: fix ARM64 alignment fault in fib_multipath_hash_from_keys()
  2026-02-26 12:02 ` Eric Dumazet
@ 2026-02-26 14:49   ` Sam Su
  2026-02-26 15:00     ` Eric Dumazet
  0 siblings, 1 reply; 7+ messages in thread
From: Sam Su @ 2026-02-26 14:49 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: davem, dsahern, kuba, pabeni, horms, nathan,
	nick.desaulniers+lkml, morbo, justinstitt, netdev, linux-kernel,
	llvm

Eric Dumazet <edumazet@google.com> 於 2026年2月26日週四 下午8:02寫道:
>
> On Thu, Feb 26, 2026 at 12:18 PM Yung Chih Su <yuuchihsu@gmail.com> wrote:
> >
> > struct sysctl_fib_multipath_hash_seed contains two u32 fields (user_seed
> > and mp_seed), making it an 8-byte structure with a 4-byte alignment requirement.
> >
> > In fib_multipath_hash_from_keys(), the code evaluates the entire struct
> > atomically via READ_ONCE():
> >
> > mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed;
> > While this silently works on GCC by falling back to unaligned regular loads
> > (e.g., LDR/LDUR) which the ARM64 kernel tolerates, it causes a fatal kernel
> > panic when compiled with Clang and LTO enabled.
> >
> > Commit e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when
> > CONFIG_LTO=y") strengthens READ_ONCE() to use Load-Acquire instructions
> > (ldar / ldapr) to prevent compiler reordering bugs under Clang LTO.
> >
> > Since the macro evaluates the full 8-byte struct, Clang emits a 64-bit
> > ldar instruction. ARM64 architecture strictly requires ldar to be
> > naturally aligned. Executing a 64-bit ldar on a 4-byte aligned address
> > (e.g., ending in 0xEC) triggers a strict Alignment Fault (FSC = 0x21).
> >
> > Fix this by moving the READ_ONCE() directly to the specific u32 member:
> >
> > mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed);
> > This instructs the compiler to emit a 32-bit load (ldar Wn or ldr Wn),
> > which perfectly satisfies the 4-byte alignment requirement and resolves
> > the crash.
> >
> > Fixes: [4ee2a8cace3fb9a34aea6a56426f89d26dd514f3] ("net: ipv4: Add a sysctl to set multipath hash seed")
> > Signed-off-by: Yung Chih Su <yuuchihsu@gmail.com>
> > ---
> >  include/net/ip_fib.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
> > index b4495c38e0a0..318593743b6e 100644
> > --- a/include/net/ip_fib.h
> > +++ b/include/net/ip_fib.h
> > @@ -559,7 +559,7 @@ static inline u32 fib_multipath_hash_from_keys(const struct net *net,
> >         siphash_aligned_key_t hash_key;
> >         u32 mp_seed;
> >
> > -       mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed;
> > +       mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed);
> >         fib_multipath_hash_construct_key(&hash_key, mp_seed);
> >
> >         return flow_hash_from_keys_seed(keys, &hash_key);
>
> What about proc_fib_multipath_hash_set_seed() ?
>
> It has :
>
> WRITE_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed, new);
>
> Which is IMO strange, regardless of ARM64 clang and whats not.

Hi Eric,

Thank you for taking a look and catching this!

You are absolutely right. If READ_ONCE() on this 4-byte aligned struct
causes an unaligned load-acquire (ldar) fault on ARM64, the
WRITE_ONCE() in proc_fib_multipath_hash_set_seed() will inevitably
cause an unaligned store-release (stlr) fault when a user tries to
modify the sysctl. Using WRITE_ONCE() on an entire struct here is
indeed structurally flawed and unsafe.

To fix the write side properly, I should write the members
individually to ensure safe 32-bit atomic operations. I am thinking of
updating proc_fib_multipath_hash_set_seed() to something like this:

    WRITE_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.user_seed,
new.user_seed);
    WRITE_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed, new.mp_seed);

I would like to take a little bit of time to reproduce the
WRITE_ONCE() crash on my ARM64 device and thoroughly test this
proposed fix to ensure everything works correctly.
Once I confirm the fix is solid and runs perfectly on the hardware, I
will submit the v2 patch addressing both the read and write sides of
this unaligned struct issue.
Thanks again for the insightful review!

Best regards,
Yung Chih.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] net: ipv6: fix ARM64 alignment fault in fib_multipath_hash_from_keys()
  2026-02-26 14:49   ` Sam Su
@ 2026-02-26 15:00     ` Eric Dumazet
  0 siblings, 0 replies; 7+ messages in thread
From: Eric Dumazet @ 2026-02-26 15:00 UTC (permalink / raw)
  To: Sam Su
  Cc: davem, dsahern, kuba, pabeni, horms, nathan,
	nick.desaulniers+lkml, morbo, justinstitt, netdev, linux-kernel,
	llvm

On Thu, Feb 26, 2026 at 3:50 PM Sam Su <yuuchihsu@gmail.com> wrote:
>
> Eric Dumazet <edumazet@google.com> 於 2026年2月26日週四 下午8:02寫道:
> >
> > On Thu, Feb 26, 2026 at 12:18 PM Yung Chih Su <yuuchihsu@gmail.com> wrote:
> > >
> > > struct sysctl_fib_multipath_hash_seed contains two u32 fields (user_seed
> > > and mp_seed), making it an 8-byte structure with a 4-byte alignment requirement.
> > >
> > > In fib_multipath_hash_from_keys(), the code evaluates the entire struct
> > > atomically via READ_ONCE():
> > >
> > > mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed;
> > > While this silently works on GCC by falling back to unaligned regular loads
> > > (e.g., LDR/LDUR) which the ARM64 kernel tolerates, it causes a fatal kernel
> > > panic when compiled with Clang and LTO enabled.
> > >
> > > Commit e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when
> > > CONFIG_LTO=y") strengthens READ_ONCE() to use Load-Acquire instructions
> > > (ldar / ldapr) to prevent compiler reordering bugs under Clang LTO.
> > >
> > > Since the macro evaluates the full 8-byte struct, Clang emits a 64-bit
> > > ldar instruction. ARM64 architecture strictly requires ldar to be
> > > naturally aligned. Executing a 64-bit ldar on a 4-byte aligned address
> > > (e.g., ending in 0xEC) triggers a strict Alignment Fault (FSC = 0x21).
> > >
> > > Fix this by moving the READ_ONCE() directly to the specific u32 member:
> > >
> > > mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed);
> > > This instructs the compiler to emit a 32-bit load (ldar Wn or ldr Wn),
> > > which perfectly satisfies the 4-byte alignment requirement and resolves
> > > the crash.
> > >
> > > Fixes: [4ee2a8cace3fb9a34aea6a56426f89d26dd514f3] ("net: ipv4: Add a sysctl to set multipath hash seed")
> > > Signed-off-by: Yung Chih Su <yuuchihsu@gmail.com>
> > > ---
> > >  include/net/ip_fib.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
> > > index b4495c38e0a0..318593743b6e 100644
> > > --- a/include/net/ip_fib.h
> > > +++ b/include/net/ip_fib.h
> > > @@ -559,7 +559,7 @@ static inline u32 fib_multipath_hash_from_keys(const struct net *net,
> > >         siphash_aligned_key_t hash_key;
> > >         u32 mp_seed;
> > >
> > > -       mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed;
> > > +       mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed);
> > >         fib_multipath_hash_construct_key(&hash_key, mp_seed);
> > >
> > >         return flow_hash_from_keys_seed(keys, &hash_key);
> >
> > What about proc_fib_multipath_hash_set_seed() ?
> >
> > It has :
> >
> > WRITE_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed, new);
> >
> > Which is IMO strange, regardless of ARM64 clang and whats not.
>
> Hi Eric,
>
> Thank you for taking a look and catching this!
>
> You are absolutely right. If READ_ONCE() on this 4-byte aligned struct
> causes an unaligned load-acquire (ldar) fault on ARM64, the
> WRITE_ONCE() in proc_fib_multipath_hash_set_seed() will inevitably
> cause an unaligned store-release (stlr) fault when a user tries to
> modify the sysctl. Using WRITE_ONCE() on an entire struct here is
> indeed structurally flawed and unsafe.
>
> To fix the write side properly, I should write the members
> individually to ensure safe 32-bit atomic operations. I am thinking of
> updating proc_fib_multipath_hash_set_seed() to something like this:
>
>     WRITE_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.user_seed,
> new.user_seed);

SGTM, but please add this part as well:
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 643763bc214279047c90b5b92a9ba9be6c24a443..1974b826bd9451fd9d8054e1db811760ff4b5a9f
100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -500,7 +500,7 @@ static int proc_fib_multipath_hash_seed(const
struct ctl_table *table, int write
        int ret;

        mphs = &net->ipv4.sysctl_fib_multipath_hash_seed;
-       user_seed = mphs->user_seed;
+       user_seed = READ_ONCE(mphs->user_seed);

        tmp = *table;
        tmp.data = &user_seed;

>     WRITE_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed.mp_seed, new.mp_seed);
>
> I would like to take a little bit of time to reproduce the
> WRITE_ONCE() crash on my ARM64 device and thoroughly test this
> proposed fix to ensure everything works correctly.
> Once I confirm the fix is solid and runs perfectly on the hardware, I
> will submit the v2 patch addressing both the read and write sides of
> this unaligned struct issue.
> Thanks again for the insightful review!
>
> Best regards,
> Yung Chih.

Thanks !

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] net: ipv6: fix ARM64 alignment fault in fib_multipath_hash_from_keys()
  2026-02-26 11:17 [PATCH] net: ipv6: fix ARM64 alignment fault in fib_multipath_hash_from_keys() Yung Chih Su
  2026-02-26 12:02 ` Eric Dumazet
@ 2026-02-27  1:14 ` Jakub Kicinski
  2026-02-27  7:12   ` Sam Su
  1 sibling, 1 reply; 7+ messages in thread
From: Jakub Kicinski @ 2026-02-27  1:14 UTC (permalink / raw)
  To: Yung Chih Su
  Cc: davem, dsahern, edumazet, pabeni, horms, nathan,
	nick.desaulniers+lkml, morbo, justinstitt, netdev, linux-kernel,
	llvm

On Thu, 26 Feb 2026 19:17:21 +0800 Yung Chih Su wrote:
> Fixes: [4ee2a8cace3fb9a34aea6a56426f89d26dd514f3] ("net: ipv4: Add a sysctl to set multipath hash seed")

Please use the traditional abbreviated format of the Fixes tag

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] net: ipv6: fix ARM64 alignment fault in fib_multipath_hash_from_keys()
  2026-02-27  1:14 ` Jakub Kicinski
@ 2026-02-27  7:12   ` Sam Su
  2026-03-02  6:13     ` Sam Su
  0 siblings, 1 reply; 7+ messages in thread
From: Sam Su @ 2026-02-27  7:12 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: davem, dsahern, edumazet, pabeni, horms, nathan,
	nick.desaulniers+lkml, morbo, justinstitt, netdev, linux-kernel,
	llvm

Jakub Kicinski <kuba@kernel.org> 於 2026年2月27日週五 上午9:14寫道:
>
> On Thu, 26 Feb 2026 19:17:21 +0800 Yung Chih Su wrote:
> > Fixes: [4ee2a8cace3fb9a34aea6a56426f89d26dd514f3] ("net: ipv4: Add a sysctl to set multipath hash seed")
>
> Please use the traditional abbreviated format of the Fixes tag

Hi Jakub,

Got it, my apologies for the formatting mistake.
I will format it strictly as 12-char abbreviated without brackets in
the upcoming v2 patch:
Fixes: 4ee2a8cace3f ("net: ipv4: Add a sysctl to set multipath hash seed")

I am currently preparing the v2 patch which will also include Eric
Dumazet's suggestion regarding the WRITE_ONCE() and READ_ONCE() on the
sysctl read/write side.
 I will send out the v2 after my local testing is done.

Thanks for the review!

Best regards,
Yung Chih

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] net: ipv6: fix ARM64 alignment fault in fib_multipath_hash_from_keys()
  2026-02-27  7:12   ` Sam Su
@ 2026-03-02  6:13     ` Sam Su
  0 siblings, 0 replies; 7+ messages in thread
From: Sam Su @ 2026-03-02  6:13 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: davem, dsahern, edumazet, pabeni, horms, nathan,
	nick.desaulniers+lkml, morbo, justinstitt, netdev, linux-kernel,
	llvm

Hi Eric,

I just sent out the v2 patch, which includes this missing READ_ONCE()
fix for the read side as you suggested.

I also wanted to share a quick update on the WRITE_ONCE() behavior we
discussed. I tested the sysctl write on my ARM64 device and dumped the
assembly. Surprisingly, the original code didn't crash.

Looking at the objdump, because the ARM64 kernel workaround for Clang
LTO (commit e35123d83ee3) only strengthens the read side to use `ldar`
(Load-Acquire), the WRITE_ONCE() here falls back to regular store
instructions. Clang actually splits the 8-byte struct write into two
separate 32-bit `str Wn` instructions:

    b905ae68      str     w8, [x19, #0x5ac]  // user_seed
    b905b268      str     w8, [x19, #0x5b0]  // mp_seed

This completely confirms your concern: the current WRITE_ONCE(struct)
quietly destroys atomicity and exposes a tear-write vulnerability
without crashing the hardware.

Splitting it explicitly into two 32-bit WRITE_ONCE() calls in the v2
patch was definitely the right move. I have tested all these changes
on my ARM64 board, and everything works perfectly.

Thanks again for the review and guidance!

Best regards,
Yung Chih.

Sam Su <yuuchihsu@gmail.com> 於 2026年2月27日週五 下午3:12寫道:
>
> Jakub Kicinski <kuba@kernel.org> 於 2026年2月27日週五 上午9:14寫道:
> >
> > On Thu, 26 Feb 2026 19:17:21 +0800 Yung Chih Su wrote:
> > > Fixes: [4ee2a8cace3fb9a34aea6a56426f89d26dd514f3] ("net: ipv4: Add a sysctl to set multipath hash seed")
> >
> > Please use the traditional abbreviated format of the Fixes tag
>
> Hi Jakub,
>
> Got it, my apologies for the formatting mistake.
> I will format it strictly as 12-char abbreviated without brackets in
> the upcoming v2 patch:
> Fixes: 4ee2a8cace3f ("net: ipv4: Add a sysctl to set multipath hash seed")
>
> I am currently preparing the v2 patch which will also include Eric
> Dumazet's suggestion regarding the WRITE_ONCE() and READ_ONCE() on the
> sysctl read/write side.
>  I will send out the v2 after my local testing is done.
>
> Thanks for the review!
>
> Best regards,
> Yung Chih

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2026-03-02  6:13 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-26 11:17 [PATCH] net: ipv6: fix ARM64 alignment fault in fib_multipath_hash_from_keys() Yung Chih Su
2026-02-26 12:02 ` Eric Dumazet
2026-02-26 14:49   ` Sam Su
2026-02-26 15:00     ` Eric Dumazet
2026-02-27  1:14 ` Jakub Kicinski
2026-02-27  7:12   ` Sam Su
2026-03-02  6:13     ` Sam Su

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox