Re: [PATCH net v2] macsec: initialize SecY before registering the netdevice

[Haseeb Malik]

Thanks, you're right. I picked the commit that introduced the warning,
but the initialization order goes back to the original MACsec driver.

Corrected the Fixes tag to c09440f7dcb3 in v3:
https://lore.kernel.org/netdev/20260921-fix-macsec-net-v3-1-accf94f93f5e@xxxxxxxxx/

Thanks,
Haseeb

On Mon, Sep 21, 2026 at 5:29 AM Sabrina Dubroca <sd@xxxxxxxxxxxxxxx> wrote:
>
> 2026-09-18, 15:01:29 -0400, Haseeb Malik via B4 Relay wrote:
> > From: Haseeb Malik <haseebulhaq55@xxxxxxxxx>
> >
> > Creating a MACsec device with MAC offload over an LRO-capable lower
> > device triggers a warning in rtmsg_ifinfo_build_skb() when IPv4
> > forwarding is enabled by default.
> >
> > register_netdevice() invokes inetdev_init(), which disables LRO and emits
> > a NETDEV_FEAT_CHANGE notification. This reaches macsec_fill_info() before
> > macsec_add_dev() initializes the SecY. key_len is still zero, so
> > macsec_fill_info() returns -EMSGSIZE and trips the WARN_ON in
> > rtmsg_ifinfo_build_skb(), even though the skb has enough space.
> >
> > Initialize the SecY and apply the new-link attributes before registration.
> > Move MAC address inheritance into macsec_newlink() so the SCI can also be
> > initialized before registration-time notifications report it. Move the
> > per-CPU statistics and metadata destination allocation into ndo_init(),
> > and release partial allocations on failure.
> >
> > Fixes: ccfdec908922 ("macsec: Add support for GCM-AES-256 cipher suite")
>
> Why this commit? The "register, then init SCI etc" order of operations
> has existed since day 1. Without ccfdec908922 we don't hit the WARN_ON
> in rtmsg_ifinfo_build_skb, but the bit fixed by "Registration can
> notify listeners before returning." would still be bogus.
>
> The patch itself looks ok. Thanks for picking this up, things got
> crazy and I forgot about it.
>
> --
> Sabrina