Historically, the Linux kernel has supported compiling the IPv6 stack as
a loadable module. While this made sense in the early days of IPv6
adoption, modern deployments and distributions overwhelmingly either
build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
no practical benefit today.

To allow core networking, BPF, Netfilter, and various device drivers to
safely interact with a potentially unloaded IPv6 module, the kernel
relies on indirect call structures like ipv6_stub, ipv6_bpf_stub, and
nf_ipv6_ops, along with dynamic RCU registrations for things like ICMPv6
senders.

This patch series addresses this by changing CONFIG_IPV6 from a tristate
to a boolean, enforcing that IPv6 is either built-in or disabled. This
allows us to completely rip out the stub infrastructures and safely
replace them with direct function calls.

All the patches has been independently build tested. With allmodconfig
and allmodconfig + CONFIG_IPV6=n. In addition, IPv6 core network
selftest has been run against them.

The series applied as a whole as been tested with allyesconfig and also
allyesconfig + CONFIG_IPV6=n but not all patches has been independently
tested this way.

This will like need to wait for [1] and [2] to be applied to avoid
conflicts from net tree and rebased in top of them.

[1] https://lore.kernel.org/netdev/20260307-net-nd_tbl_fixes-v4-0-e2677e85628c@suse.com/

[2] https://lore.kernel.org/netdev/20260308032304.1841198-1-kuniyu@google.com/

Fernando Fernandez Mancera (10):
  ipv6: convert CONFIG_IPV6 to built-in only and clean up Kconfigs
  ipv6: replace IS_BUILTIN(CONFIG_IPV6) with IS_ENABLED(CONFIG_IPV6)
  ipv6: remove dynamic ICMPv6 sender registration infrastructure
  ipv6: prepare headers for ipv6_stub removal
  drivers: net: drop ipv6_stub usage and use direct function calls
  ipv4: drop ipv6_stub usage and use direct function calls
  net: convert remaining ipv6_stub users to direct function calls
  bpf: remove ipv6_bpf_stub completely and use direct function calls
  ipv6: remove ipv6_stub infrastructure completely
  netfilter: remove nf_ipv6_ops and use direct function calls

 arch/arm64/configs/defconfig                  |   2 +-
 arch/m68k/configs/amiga_defconfig             |   2 +-
 arch/m68k/configs/apollo_defconfig            |   2 +-
 arch/m68k/configs/atari_defconfig             |   2 +-
 arch/m68k/configs/bvme6000_defconfig          |   2 +-
 arch/m68k/configs/hp300_defconfig             |   2 +-
 arch/m68k/configs/mac_defconfig               |   2 +-
 arch/m68k/configs/multi_defconfig             |   2 +-
 arch/m68k/configs/mvme147_defconfig           |   2 +-
 arch/m68k/configs/mvme16x_defconfig           |   2 +-
 arch/m68k/configs/q40_defconfig               |   2 +-
 arch/m68k/configs/sun3_defconfig              |   2 +-
 arch/m68k/configs/sun3x_defconfig             |   2 +-
 drivers/infiniband/Kconfig                    |   1 -
 drivers/infiniband/core/addr.c                |   3 +-
 drivers/infiniband/hw/ocrdma/Kconfig          |   2 +-
 drivers/infiniband/sw/rxe/rxe_net.c           |   6 +-
 drivers/infiniband/ulp/ipoib/Kconfig          |   2 +-
 drivers/net/Kconfig                           |   9 --
 drivers/net/ethernet/broadcom/Kconfig         |   2 +-
 drivers/net/ethernet/chelsio/Kconfig          |   2 +-
 .../mellanox/mlx5/core/en/rep/neigh.c         |  11 +-
 .../ethernet/mellanox/mlx5/core/en/tc_tun.c   |   3 +-
 .../mellanox/mlx5/core/en/tc_tun_encap.c      |   2 +-
 .../mellanox/mlx5/core/en_accel/ipsec.c       |   1 -
 .../net/ethernet/mellanox/mlx5/core/en_rep.c  |   1 -
 .../net/ethernet/mellanox/mlx5/core/en_tc.c   |   1 -
 drivers/net/ethernet/mellanox/mlxsw/Kconfig   |   1 -
 .../ethernet/mellanox/mlxsw/spectrum_router.c |   8 +-
 .../ethernet/mellanox/mlxsw/spectrum_span.c   |   2 +-
 drivers/net/ethernet/netronome/Kconfig        |   1 -
 .../ethernet/netronome/nfp/flower/action.c    |   2 +-
 .../netronome/nfp/flower/tunnel_conf.c        |   9 +-
 drivers/net/ethernet/sfc/tc_counters.c        |   2 +-
 drivers/net/ethernet/sfc/tc_encap_actions.c   |   5 +-
 drivers/net/geneve.c                          |   1 -
 drivers/net/gtp.c                             |   2 +-
 drivers/net/ovpn/peer.c                       |   3 +-
 drivers/net/ovpn/udp.c                        |   3 +-
 drivers/net/usb/cdc_mbim.c                    |  17 +--
 drivers/net/vrf.c                             |   2 +-
 drivers/net/vxlan/vxlan_core.c                |  11 +-
 drivers/net/vxlan/vxlan_multicast.c           |   6 +-
 drivers/net/wireguard/socket.c                |   3 +-
 drivers/net/wireless/intel/ipw2x00/ipw2100.c  |   2 +-
 drivers/scsi/bnx2fc/Kconfig                   |   1 -
 drivers/scsi/bnx2i/Kconfig                    |   1 -
 drivers/scsi/cxgbi/cxgb3i/Kconfig             |   2 +-
 drivers/scsi/cxgbi/cxgb4i/Kconfig             |   2 +-
 fs/dlm/Kconfig                                |   2 +-
 fs/gfs2/Kconfig                               |   2 +-
 include/linux/icmpv6.h                        |  26 +----
 include/linux/indirect_call_wrapper.h         |   2 +-
 include/linux/netfilter_ipv6.h                | 102 ++----------------
 include/net/ip.h                              |   5 -
 include/net/ip6_fib.h                         |  33 +++++-
 include/net/ip6_route.h                       |  25 +++++
 include/net/ipv6.h                            |  12 +++
 include/net/ipv6_stubs.h                      | 102 ------------------
 include/net/ndisc.h                           |  39 +++----
 include/net/udp_tunnel.h                      |   3 +-
 net/bridge/Kconfig                            |   1 -
 net/bridge/br_arp_nd_proxy.c                  |   3 +-
 net/bridge/br_netfilter_hooks.c               |  12 +--
 net/bridge/br_netfilter_ipv6.c                |   7 +-
 net/core/filter.c                             |  70 ++++++------
 net/core/lwt_bpf.c                            |  10 +-
 net/ieee802154/6lowpan/tx.c                   |   2 +-
 net/ipv4/Kconfig                              |   9 +-
 net/ipv4/fib_semantics.c                      |  11 +-
 net/ipv4/icmp.c                               |   2 +-
 net/ipv4/nexthop.c                            |  21 ++--
 net/ipv4/route.c                              |   2 +-
 net/ipv4/udp.c                                |   7 +-
 net/ipv6/Kconfig                              |   6 +-
 net/ipv6/addrconf.c                           |  10 +-
 net/ipv6/addrconf_core.c                      |  91 ----------------
 net/ipv6/af_inet6.c                           |  69 ++----------
 net/ipv6/icmp.c                               |   6 --
 net/ipv6/ip6_fib.c                            |  10 +-
 net/ipv6/ip6_icmp.c                           |  46 +-------
 net/ipv6/ip6_offload.c                        |   4 +-
 net/ipv6/ip6_output.c                         |   5 +-
 net/ipv6/ip6_udp_tunnel.c                     |   3 +-
 net/ipv6/ndisc.c                              |  35 +++---
 net/ipv6/netfilter.c                          |  48 ---------
 net/ipv6/route.c                              |  13 +--
 net/l2tp/Kconfig                              |   1 -
 net/mpls/af_mpls.c                            |   3 +-
 net/netfilter/Kconfig                         |   8 --
 net/netfilter/core.c                          |   3 -
 net/netfilter/nf_nat_masquerade.c             |  21 +---
 net/netfilter/nfnetlink_queue.c               |  22 +++-
 net/netfilter/utils.c                         |   1 -
 net/openvswitch/actions.c                     |   3 +-
 net/rxrpc/Kconfig                             |   2 +-
 net/sched/sch_frag.c                          |   4 +-
 net/sctp/Kconfig                              |   1 -
 net/tipc/Kconfig                              |   1 -
 net/tipc/udp_media.c                          |   9 +-
 net/xfrm/espintcp.c                           |   5 +-
 net/xfrm/xfrm_nat_keepalive.c                 |   4 +-
 net/xfrm/xfrm_output.c                        |   3 +-
 103 files changed, 310 insertions(+), 795 deletions(-)
 delete mode 100644 include/net/ipv6_stubs.h

-- 
2.53.0

On 09/03/2026 03:19, Fernando Fernandez Mancera wrote:
> Historically, the Linux kernel has supported compiling the IPv6 stack as
> a loadable module. While this made sense in the early days of IPv6
> adoption, modern deployments and distributions overwhelmingly either
> build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
> entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
> no practical benefit today.

It does. We all use generic kernels, thus it is one configuration for
all boards and some setups have IPv6 and some not. The ones without IPv6
just don't use that module.

Also, with these generic kernels (so again all machines are using same
ones, e.g. distro) users can easily blacklist the module.

Best regards,
Krzysztof

On 3/9/26 11:22 AM, Krzysztof Kozlowski wrote:
> On 09/03/2026 03:19, Fernando Fernandez Mancera wrote:
>> Historically, the Linux kernel has supported compiling the IPv6 stack as
>> a loadable module. While this made sense in the early days of IPv6
>> adoption, modern deployments and distributions overwhelmingly either
>> build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
>> entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
>> no practical benefit today.
> 
> It does. We all use generic kernels, thus it is one configuration for
> all boards and some setups have IPv6 and some not. The ones without IPv6
> just don't use that module.
>

While I understand this, I would like to clarify that IMHO IPv6 isn't a 
secondary protocol and it is fundamental to modern networking. This is 
why I believe it should be built-in by default. Currently OpenWRT, 
Debian ARM and others already ships the kernel with CONFIG_IPV6=y. I 
know that Alpine and Yocto doesn't do that for arm64.

I guess the most critical one here is Yocto but if the developer of the 
embedded device is sure they won't use IPv6 at all, they should turn it off.

At the same time, Alpine ships software that enable IPV6 and is 
frequently loaded as a module. So the only remaining concern would be 
the boot partition size. I don't really have a solution for that problem.

I think that the infrastructure for allowing IPV6=m is bug-prone and it 
impacts performance. Forcing the use of indirect function calls in core 
networking, Netfilter or BPF datapaths seems like a heavy tax to me.

> Also, with these generic kernels (so again all machines are using same
> ones, e.g. distro) users can easily blacklist the module.
> 

FWIW; users can still boot with kernel command line parameter 
ipv6.disable=1 and then IPV6 will be administratively disabled.

At the end this a trade-off, I still believe it is worth it but I 
understand your concerns.

Thanks,
Fernando.

On 09/03/2026 12:38, Fernando Fernandez Mancera wrote:
> On 3/9/26 11:22 AM, Krzysztof Kozlowski wrote:
>> On 09/03/2026 03:19, Fernando Fernandez Mancera wrote:
>>> Historically, the Linux kernel has supported compiling the IPv6 stack as
>>> a loadable module. While this made sense in the early days of IPv6
>>> adoption, modern deployments and distributions overwhelmingly either
>>> build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
>>> entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
>>> no practical benefit today.
>>
>> It does. We all use generic kernels, thus it is one configuration for
>> all boards and some setups have IPv6 and some not. The ones without IPv6
>> just don't use that module.
>>
> 
> While I understand this, I would like to clarify that IMHO IPv6 isn't a 
> secondary protocol and it is fundamental to modern networking. This is 

Not for end user devices. None of my devices - neither routers, nor
embedded boards, nor mobile phone from 5G provider - receive IPv6
address, thus for them it is not fundamental.

I agree it is fundamental for your cloud machines and network backbone
which you are targeting, but this patchset completely ignores other
users calling their use-cases "little practical benefit"! Try running
Amiga machine...

There is no even bloatometer stats for these defconfigs so we can see
the impact.

> why I believe it should be built-in by default. Currently OpenWRT, 
> Debian ARM and others already ships the kernel with CONFIG_IPV6=y. I 
> know that Alpine and Yocto doesn't do that for arm64.

Maybe there are other reasons why distro should not choose it as module
(like module load calls on ipv6 packets) but that was not explained here.

Arch Linux Rpi kernel on arm64 has IPV6=6 and the module itself is 650
kB. That's noticeable for smaller arm64 boards.

For arm it would be even more noticeable as some have 256 MB RAM like
first Rpi.

> 
> I guess the most critical one here is Yocto but if the developer of the 
> embedded device is sure they won't use IPv6 at all, they should turn it off.
> 
> At the same time, Alpine ships software that enable IPV6 and is 
> frequently loaded as a module. So the only remaining concern would be 
> the boot partition size. I don't really have a solution for that problem.
> 
> I think that the infrastructure for allowing IPV6=m is bug-prone and it 
> impacts performance. Forcing the use of indirect function calls in core 
> networking, Netfilter or BPF datapaths seems like a heavy tax to me.
> 
>> Also, with these generic kernels (so again all machines are using same
>> ones, e.g. distro) users can easily blacklist the module.
>>
> 
> FWIW; users can still boot with kernel command line parameter 
> ipv6.disable=1 and then IPV6 will be administratively disabled.

It's not the same. You enabled it on amiga_defconfig and do you
understand what sort of machine is that? The newest have 16 MB RAM, many
much less like 2 MB, and ipv6 module on m68k is 400 kB, so pretty
significant change.

Best regards,
Krzysztof

On 3/9/26 1:43 PM, Krzysztof Kozlowski wrote:
> On 09/03/2026 12:38, Fernando Fernandez Mancera wrote:
>> On 3/9/26 11:22 AM, Krzysztof Kozlowski wrote:
>>> On 09/03/2026 03:19, Fernando Fernandez Mancera wrote:
>>>> Historically, the Linux kernel has supported compiling the IPv6 stack as
>>>> a loadable module. While this made sense in the early days of IPv6
>>>> adoption, modern deployments and distributions overwhelmingly either
>>>> build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
>>>> entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
>>>> no practical benefit today.
>>>
>>> It does. We all use generic kernels, thus it is one configuration for
>>> all boards and some setups have IPv6 and some not. The ones without IPv6
>>> just don't use that module.
>>>
>>
>> While I understand this, I would like to clarify that IMHO IPv6 isn't a
>> secondary protocol and it is fundamental to modern networking. This is
> 
> Not for end user devices. None of my devices - neither routers, nor
> embedded boards, nor mobile phone from 5G provider - receive IPv6
> address, thus for them it is not fundamental.
> 

I am not so sure about this. Many if not most modern routers provide 
IPv6 support and as I said it is enabled as built-in in openWRT since 
[1]. For mobile phones they probably use IPv6 when connected to routers 
but even 5G providers are using IPv6. They are working on IPv6-only 
deployments with NAT64 too [2].

[1] 
https://github.com/openwrt/openwrt/commit/0c8f0186d58468024db96a5ab0ca36a4d400d408

[2] https://www.ietf.org/archive/id/draft-ma-v6ops-5g-ipv6only-01.html

> I agree it is fundamental for your cloud machines and network backbone
> which you are targeting, but this patchset completely ignores other
> users calling their use-cases "little practical benefit"! Try running
> Amiga machine...
> 
> There is no even bloatometer stats for these defconfigs so we can see
> the impact.
> 

Sure. I can provide them.

>> why I believe it should be built-in by default. Currently OpenWRT,
>> Debian ARM and others already ships the kernel with CONFIG_IPV6=y. I
>> know that Alpine and Yocto doesn't do that for arm64.
> 
> Maybe there are other reasons why distro should not choose it as module
> (like module load calls on ipv6 packets) but that was not explained here.
> 
> Arch Linux Rpi kernel on arm64 has IPV6=6 and the module itself is 650
> kB. That's noticeable for smaller arm64 boards.
> 
> For arm it would be even more noticeable as some have 256 MB RAM like
> first Rpi.
> 
>>
>> I guess the most critical one here is Yocto but if the developer of the
>> embedded device is sure they won't use IPv6 at all, they should turn it off.
>>
>> At the same time, Alpine ships software that enable IPV6 and is
>> frequently loaded as a module. So the only remaining concern would be
>> the boot partition size. I don't really have a solution for that problem.
>>
>> I think that the infrastructure for allowing IPV6=m is bug-prone and it
>> impacts performance. Forcing the use of indirect function calls in core
>> networking, Netfilter or BPF datapaths seems like a heavy tax to me.
>>
>>> Also, with these generic kernels (so again all machines are using same
>>> ones, e.g. distro) users can easily blacklist the module.
>>>
>>
>> FWIW; users can still boot with kernel command line parameter
>> ipv6.disable=1 and then IPV6 will be administratively disabled.
> 
> It's not the same. You enabled it on amiga_defconfig and do you
> understand what sort of machine is that? The newest have 16 MB RAM, many
> much less like 2 MB, and ipv6 module on m68k is 400 kB, so pretty
> significant change.
> 

Fair enough. Of course I am not familiar with all the architectures 
affected. This feedback is more than welcome and it might make a lot of 
sense to disable IPv6 on Amiga and probably different architectures. By 
the way if by Amiga you mean [3] then I believe it should be disabled.

[3] https://en.wikipedia.org/wiki/Amiga

Thanks,
Fernando.

On 3/9/26 1:43 PM, Krzysztof Kozlowski wrote:
> On 09/03/2026 12:38, Fernando Fernandez Mancera wrote:
>> On 3/9/26 11:22 AM, Krzysztof Kozlowski wrote:
>>> On 09/03/2026 03:19, Fernando Fernandez Mancera wrote:
>>>> Historically, the Linux kernel has supported compiling the IPv6 stack as
>>>> a loadable module. While this made sense in the early days of IPv6
>>>> adoption, modern deployments and distributions overwhelmingly either
>>>> build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
>>>> entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
>>>> no practical benefit today.
>>>
>>> It does. We all use generic kernels, thus it is one configuration for
>>> all boards and some setups have IPv6 and some not. The ones without IPv6
>>> just don't use that module.
>>
>> While I understand this, I would like to clarify that IMHO IPv6 isn't a
>> secondary protocol and it is fundamental to modern networking. This is
> 
> Not for end user devices. None of my devices - neither routers, nor
> embedded boards, nor mobile phone from 5G provider - receive IPv6
> address, thus for them it is not fundamental.

If that is the case for them, then they should just CONFIG_IPV6=n.

> I agree it is fundamental for your cloud machines and network backbone
> which you are targeting, but this patchset completely ignores other
> users calling their use-cases "little practical benefit"! Try running
> Amiga machine...

Are you talking about [0]? That's legacy hardware and in this case just
disable IPv6 altogether, why would you still prefer to have it as a module?

   [0] https://en.wikipedia.org/wiki/Amiga

> There is no even bloatometer stats for these defconfigs so we can see
> the impact.
> 
>> why I believe it should be built-in by default. Currently OpenWRT,
>> Debian ARM and others already ships the kernel with CONFIG_IPV6=y. I
>> know that Alpine and Yocto doesn't do that for arm64.
> 
> Maybe there are other reasons why distro should not choose it as module
> (like module load calls on ipv6 packets) but that was not explained here.
> 
> Arch Linux Rpi kernel on arm64 has IPV6=6 and the module itself is 650
> kB. That's noticeable for smaller arm64 boards.
> 
> For arm it would be even more noticeable as some have 256 MB RAM like
> first Rpi.

You are arguing that these will never be able to migrate to an IPv6 world
given their memory is too small?

>> I guess the most critical one here is Yocto but if the developer of the
>> embedded device is sure they won't use IPv6 at all, they should turn it off.
>>
>> At the same time, Alpine ships software that enable IPV6 and is
>> frequently loaded as a module. So the only remaining concern would be
>> the boot partition size. I don't really have a solution for that problem.
>>
>> I think that the infrastructure for allowing IPV6=m is bug-prone and it
>> impacts performance. Forcing the use of indirect function calls in core
>> networking, Netfilter or BPF datapaths seems like a heavy tax to me.
>>
>>> Also, with these generic kernels (so again all machines are using same
>>> ones, e.g. distro) users can easily blacklist the module.
>>
>> FWIW; users can still boot with kernel command line parameter
>> ipv6.disable=1 and then IPV6 will be administratively disabled.
> 
> It's not the same. You enabled it on amiga_defconfig and do you
> understand what sort of machine is that? The newest have 16 MB RAM, many
> much less like 2 MB, and ipv6 module on m68k is 400 kB, so pretty
> significant change.

If IPv6 is not relevant for amiga_defconfig presumably it should just be
set to CONFIG_IPV6=n?

Thanks,
Daniel

On 09/03/2026 13:58, Daniel Borkmann wrote:
> On 3/9/26 1:43 PM, Krzysztof Kozlowski wrote:
>> On 09/03/2026 12:38, Fernando Fernandez Mancera wrote:
>>> On 3/9/26 11:22 AM, Krzysztof Kozlowski wrote:
>>>> On 09/03/2026 03:19, Fernando Fernandez Mancera wrote:
>>>>> Historically, the Linux kernel has supported compiling the IPv6 stack as
>>>>> a loadable module. While this made sense in the early days of IPv6
>>>>> adoption, modern deployments and distributions overwhelmingly either
>>>>> build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
>>>>> entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
>>>>> no practical benefit today.
>>>>
>>>> It does. We all use generic kernels, thus it is one configuration for
>>>> all boards and some setups have IPv6 and some not. The ones without IPv6
>>>> just don't use that module.
>>>
>>> While I understand this, I would like to clarify that IMHO IPv6 isn't a
>>> secondary protocol and it is fundamental to modern networking. This is
>>
>> Not for end user devices. None of my devices - neither routers, nor
>> embedded boards, nor mobile phone from 5G provider - receive IPv6
>> address, thus for them it is not fundamental.
> 
> If that is the case for them, then they should just CONFIG_IPV6=n.

That's not a question to me. Look what I wrote: "We all use generic
kernels" - in a meaning of generic kernel, with generic defconfig built
once serving every machine.

> 
>> I agree it is fundamental for your cloud machines and network backbone
>> which you are targeting, but this patchset completely ignores other
>> users calling their use-cases "little practical benefit"! Try running
>> Amiga machine...
> 
> Are you talking about [0]? That's legacy hardware and in this case just

Dunno what is legacy there...

> disable IPv6 altogether, why would you still prefer to have it as a module?

That's not a question to me - someone added it as a module now. The
author here changes it to built-in.


> 
>    [0] https://en.wikipedia.org/wiki/Amiga
> 
>> There is no even bloatometer stats for these defconfigs so we can see
>> the impact.
>>
>>> why I believe it should be built-in by default. Currently OpenWRT,
>>> Debian ARM and others already ships the kernel with CONFIG_IPV6=y. I
>>> know that Alpine and Yocto doesn't do that for arm64.
>>
>> Maybe there are other reasons why distro should not choose it as module
>> (like module load calls on ipv6 packets) but that was not explained here.
>>
>> Arch Linux Rpi kernel on arm64 has IPV6=6 and the module itself is 650
>> kB. That's noticeable for smaller arm64 boards.
>>
>> For arm it would be even more noticeable as some have 256 MB RAM like
>> first Rpi.
> 
> You are arguing that these will never be able to migrate to an IPv6 world
> given their memory is too small?

No. I argue that they do not need IPv6 in many cases, thus use-case of
IPV6=m is perfectly valid.

The entire discussion here started with "The modular IPv6 use-case
provides little to no practical benefit today."

and this is clearly false. I brought you already few arguments of valid
use case today.

> 
>>> I guess the most critical one here is Yocto but if the developer of the
>>> embedded device is sure they won't use IPv6 at all, they should turn it off.
>>>
>>> At the same time, Alpine ships software that enable IPV6 and is
>>> frequently loaded as a module. So the only remaining concern would be
>>> the boot partition size. I don't really have a solution for that problem.
>>>
>>> I think that the infrastructure for allowing IPV6=m is bug-prone and it
>>> impacts performance. Forcing the use of indirect function calls in core
>>> networking, Netfilter or BPF datapaths seems like a heavy tax to me.
>>>
>>>> Also, with these generic kernels (so again all machines are using same
>>>> ones, e.g. distro) users can easily blacklist the module.
>>>
>>> FWIW; users can still boot with kernel command line parameter
>>> ipv6.disable=1 and then IPV6 will be administratively disabled.
>>
>> It's not the same. You enabled it on amiga_defconfig and do you
>> understand what sort of machine is that? The newest have 16 MB RAM, many
>> much less like 2 MB, and ipv6 module on m68k is 400 kB, so pretty
>> significant change.
> 
> If IPv6 is not relevant for amiga_defconfig presumably it should just be
> set to CONFIG_IPV6=n?

It might be relevant to some, but this makes it relevant to everyone on
Amiga.

There is a reason why kernel supports modules or do you suggest "modules
provide little to no practical benefit today" and let's just have
everything built-in or disabled.

Best regards,
Krzysztof

On Mon, Mar 09, 2026 at 02:02:45PM +0100, Krzysztof Kozlowski wrote:
> > Are you talking about [0]? That's legacy hardware and in this case just
>
> Dunno what is legacy there...
>

Is this satire?

I'm not sure why you're being quite so aggressive in your response overall
here, but Amiga is ABSOLUTELY legacy and you are delusional if you think
otherwise?

I think the kernel should absolutely drop support for it, museum pieces
like this cause undue maintenance burden, and sorry not sorry - if you own
hardware that old, live with using older kernels.

In any case this kind of facecious engagement, especially in response to
somebody as lovely as Fernando, is really unhelpful.

If I'm wrong and somehow Amiga isn't legacy in 2026, then SAY SO instead of
giving an unnecessarily mean, dismissive and frankly embarassing response
like the above.

[snip]

> >
> >    [0] https://en.wikipedia.org/wiki/Amiga

Thanks, Lorenzo

On 16/03/2026 11:24, Lorenzo Stoakes (Oracle) wrote:
> On Mon, Mar 09, 2026 at 02:02:45PM +0100, Krzysztof Kozlowski wrote:
>>> Are you talking about [0]? That's legacy hardware and in this case just
>>
>> Dunno what is legacy there...
>>
> 
> Is this satire?
> 
> I'm not sure why you're being quite so aggressive in your response overall
> here, but Amiga is ABSOLUTELY legacy and you are delusional if you think
> otherwise?
> 
> I think the kernel should absolutely drop support for it, museum pieces
> like this cause undue maintenance burden, and sorry not sorry - if you own
> hardware that old, live with using older kernels.
> 
> In any case this kind of facecious engagement, especially in response to
> somebody as lovely as Fernando, is really unhelpful.

Response was to Daniel. You come late to the thread, pick up one thing
and poke... great.

> 
> If I'm wrong and somehow Amiga isn't legacy in 2026, then SAY SO instead of
> giving an unnecessarily mean, dismissive and frankly embarassing response
> like the above.

Calling something legacy in this thread is not really appropriate
because it is diminishing its important or requirements.

Till we support given hardware, we are supposed to consider its
requirements. If you do not consider these requirements, then you do not
consider that hardware as worth being supported and this means you
should first propose patch to remove that hardware.

If you do not want to care about that hardware, don't use arguments
"legacy" in discussions, but simply drop it. We do such with "legacy"
architectures.

Best regards,
Krzysztof

On 3/16/26 11:33, Krzysztof Kozlowski wrote:
> On 16/03/2026 11:24, Lorenzo Stoakes (Oracle) wrote:
>> 
>> If I'm wrong and somehow Amiga isn't legacy in 2026, then SAY SO instead of
>> giving an unnecessarily mean, dismissive and frankly embarassing response
>> like the above.
> 
> Calling something legacy in this thread is not really appropriate
> because it is diminishing its important or requirements.
> 
> Till we support given hardware, we are supposed to consider its
> requirements. If you do not consider these requirements, then you do not
> consider that hardware as worth being supported and this means you
> should first propose patch to remove that hardware.

I don't think it's so binary. AFAIU (and recall also Linus saying that) it's
ok to make things less optimal for older/less common hardware, if that's the
cost to make the kernel better for the major ones. So that's why we're e.g.
discussing removing CONFIG_HIMEM which could limit how much physical RAM
some 32bit  architectures can use. Or we can have new features e.g. 64-bit only.

We can call that older/less common hardware "legacy" or "museum" or
whatever, I wouldn't say it's diminishing it, just stating a fact.

Of course the devil is in the details so that probably to some extent
depends on what exactly you mean as "requirements" above. AFAIU the
conclusion here was already that ipv6=m isn't consired one for Amiga to
stay, and it's enough to have ipv6=n there.

> If you do not want to care about that hardware, don't use arguments
> "legacy" in discussions, but simply drop it. We do such with "legacy"
> architectures.
> 
> Best regards,
> Krzysztof
>

On 16/03/2026 12:10, Vlastimil Babka wrote:
> On 3/16/26 11:33, Krzysztof Kozlowski wrote:
>> On 16/03/2026 11:24, Lorenzo Stoakes (Oracle) wrote:
>>>
>>> If I'm wrong and somehow Amiga isn't legacy in 2026, then SAY SO instead of
>>> giving an unnecessarily mean, dismissive and frankly embarassing response
>>> like the above.
>>
>> Calling something legacy in this thread is not really appropriate
>> because it is diminishing its important or requirements.
>>
>> Till we support given hardware, we are supposed to consider its
>> requirements. If you do not consider these requirements, then you do not
>> consider that hardware as worth being supported and this means you
>> should first propose patch to remove that hardware.
> 
> I don't think it's so binary. AFAIU (and recall also Linus saying that) it's
> ok to make things less optimal for older/less common hardware, if that's the
> cost to make the kernel better for the major ones. So that's why we're e.g.
> discussing removing CONFIG_HIMEM which could limit how much physical RAM
> some 32bit  architectures can use. Or we can have new features e.g. 64-bit only.
> 
> We can call that older/less common hardware "legacy" or "museum" or
> whatever, I wouldn't say it's diminishing it, just stating a fact.

Yes. Amiga was the first thing I poked to discuss affecting less capable
hardware. But we could also talk about ARM 32-bit, which is not yet
considered "legacy" because new hardware is being manufactured and sold.
Legacy in a meaning we do consider its requirements/support.

> 
> Of course the devil is in the details so that probably to some extent
> depends on what exactly you mean as "requirements" above. AFAIU the
> conclusion here was already that ipv6=m isn't consired one for Amiga to
> stay, and it's enough to have ipv6=n there.
> 

Yes, and other replies (parallel threads) also provide context and
arguments why most, not all though, distros don't even use IPV6=m, while
they are making everything else modules by default.

Best regards,
Krzysztof

On Mon, Mar 16, 2026 at 11:33:33AM +0100, Krzysztof Kozlowski wrote:
> On 16/03/2026 11:24, Lorenzo Stoakes (Oracle) wrote:
> > On Mon, Mar 09, 2026 at 02:02:45PM +0100, Krzysztof Kozlowski wrote:
> >>> Are you talking about [0]? That's legacy hardware and in this case just
> >>
> >> Dunno what is legacy there...
> >>
> >
> > Is this satire?
> >
> > I'm not sure why you're being quite so aggressive in your response overall
> > here, but Amiga is ABSOLUTELY legacy and you are delusional if you think
> > otherwise?
> >
> > I think the kernel should absolutely drop support for it, museum pieces
> > like this cause undue maintenance burden, and sorry not sorry - if you own
> > hardware that old, live with using older kernels.
> >
> > In any case this kind of facecious engagement, especially in response to
> > somebody as lovely as Fernando, is really unhelpful.
>
> Response was to Daniel. You come late to the thread, pick up one thing
> and poke... great.

I call out unpleasant/bullying behaviour when I see it, and I'm not going
to apologise for that, especially when it comes from an experienced
maintainer.

And sure, s/Fernando/Daniel/, but I'm not sure that's the
incredible riposte you seem to think it is.

I'm not going to belabour the point, being civil to people when they are
not being unreasonable should be a default, it's sad that it's not always
the case in the kernel.

>
> >
> > If I'm wrong and somehow Amiga isn't legacy in 2026, then SAY SO instead of
> > giving an unnecessarily mean, dismissive and frankly embarassing response
> > like the above.
>
> Calling something legacy in this thread is not really appropriate
> because it is diminishing its important or requirements.
>
> Till we support given hardware, we are supposed to consider its
> requirements. If you do not consider these requirements, then you do not
> consider that hardware as worth being supported and this means you
> should first propose patch to remove that hardware.
>
> If you do not want to care about that hardware, don't use arguments
> "legacy" in discussions, but simply drop it. We do such with "legacy"
> architectures.

Perhaps you could have replied with this instead of rudely making the
ludicrious claim that Amiga isn't legacy in 2026?

>
> Best regards,
> Krzysztof

Thanks, Lorenzo

On 16/03/2026 11:50, Lorenzo Stoakes (Oracle) wrote:
>>
>>>
>>> If I'm wrong and somehow Amiga isn't legacy in 2026, then SAY SO instead of
>>> giving an unnecessarily mean, dismissive and frankly embarassing response
>>> like the above.
>>
>> Calling something legacy in this thread is not really appropriate
>> because it is diminishing its important or requirements.
>>
>> Till we support given hardware, we are supposed to consider its
>> requirements. If you do not consider these requirements, then you do not
>> consider that hardware as worth being supported and this means you
>> should first propose patch to remove that hardware.
>>
>> If you do not want to care about that hardware, don't use arguments
>> "legacy" in discussions, but simply drop it. We do such with "legacy"
>> architectures.
> 
> Perhaps you could have replied with this instead of rudely making the
> ludicrious claim that Amiga isn't legacy in 2026?

Initial comment about "legacy" lacked any arguments why it is legacy,
thus I don't see what is rude in response "Dunno what is legacy
there..." except that it is not that helpful to understand the point.
Just like the original comment wasn't helpful.

Best regards,
Krzysztof

On 3/9/26 2:02 PM, Krzysztof Kozlowski wrote:
> On 09/03/2026 13:58, Daniel Borkmann wrote:
>> On 3/9/26 1:43 PM, Krzysztof Kozlowski wrote:
>>> On 09/03/2026 12:38, Fernando Fernandez Mancera wrote:
>>>> On 3/9/26 11:22 AM, Krzysztof Kozlowski wrote:
>>>>> On 09/03/2026 03:19, Fernando Fernandez Mancera wrote:
>>>>>> Historically, the Linux kernel has supported compiling the IPv6 stack as
>>>>>> a loadable module. While this made sense in the early days of IPv6
>>>>>> adoption, modern deployments and distributions overwhelmingly either
>>>>>> build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
>>>>>> entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
>>>>>> no practical benefit today.
>>>>>
>>>>> It does. We all use generic kernels, thus it is one configuration for
>>>>> all boards and some setups have IPv6 and some not. The ones without IPv6
>>>>> just don't use that module.
>>>>
>>>> While I understand this, I would like to clarify that IMHO IPv6 isn't a
>>>> secondary protocol and it is fundamental to modern networking. This is
>>>
>>> Not for end user devices. None of my devices - neither routers, nor
>>> embedded boards, nor mobile phone from 5G provider - receive IPv6
>>> address, thus for them it is not fundamental.
>>
>> If that is the case for them, then they should just CONFIG_IPV6=n.
> 
> That's not a question to me. Look what I wrote: "We all use generic
> kernels" - in a meaning of generic kernel, with generic defconfig built
> once serving every machine.
> 
>>
>>> I agree it is fundamental for your cloud machines and network backbone
>>> which you are targeting, but this patchset completely ignores other
>>> users calling their use-cases "little practical benefit"! Try running
>>> Amiga machine...
>>
>> Are you talking about [0]? That's legacy hardware and in this case just
> 
> Dunno what is legacy there...
> 
>> disable IPv6 altogether, why would you still prefer to have it as a module?
> 
> That's not a question to me - someone added it as a module now. The
> author here changes it to built-in.
> 
> 
>>
>>     [0] https://en.wikipedia.org/wiki/Amiga
>>
>>> There is no even bloatometer stats for these defconfigs so we can see
>>> the impact.
>>>
>>>> why I believe it should be built-in by default. Currently OpenWRT,
>>>> Debian ARM and others already ships the kernel with CONFIG_IPV6=y. I
>>>> know that Alpine and Yocto doesn't do that for arm64.
>>>
>>> Maybe there are other reasons why distro should not choose it as module
>>> (like module load calls on ipv6 packets) but that was not explained here.
>>>
>>> Arch Linux Rpi kernel on arm64 has IPV6=6 and the module itself is 650
>>> kB. That's noticeable for smaller arm64 boards.
>>>
>>> For arm it would be even more noticeable as some have 256 MB RAM like
>>> first Rpi.
>>
>> You are arguing that these will never be able to migrate to an IPv6 world
>> given their memory is too small?
> 
> No. I argue that they do not need IPv6 in many cases, thus use-case of
> IPV6=m is perfectly valid.
> 
> The entire discussion here started with "The modular IPv6 use-case
> provides little to no practical benefit today."
> 
> and this is clearly false. I brought you already few arguments of valid
> use case today.
> 
>>
>>>> I guess the most critical one here is Yocto but if the developer of the
>>>> embedded device is sure they won't use IPv6 at all, they should turn it off.
>>>>
>>>> At the same time, Alpine ships software that enable IPV6 and is
>>>> frequently loaded as a module. So the only remaining concern would be
>>>> the boot partition size. I don't really have a solution for that problem.
>>>>
>>>> I think that the infrastructure for allowing IPV6=m is bug-prone and it
>>>> impacts performance. Forcing the use of indirect function calls in core
>>>> networking, Netfilter or BPF datapaths seems like a heavy tax to me.
>>>>
>>>>> Also, with these generic kernels (so again all machines are using same
>>>>> ones, e.g. distro) users can easily blacklist the module.
>>>>
>>>> FWIW; users can still boot with kernel command line parameter
>>>> ipv6.disable=1 and then IPV6 will be administratively disabled.
>>>
>>> It's not the same. You enabled it on amiga_defconfig and do you
>>> understand what sort of machine is that? The newest have 16 MB RAM, many
>>> much less like 2 MB, and ipv6 module on m68k is 400 kB, so pretty
>>> significant change.
>>
>> If IPv6 is not relevant for amiga_defconfig presumably it should just be
>> set to CONFIG_IPV6=n?
> 
> It might be relevant to some, but this makes it relevant to everyone on
> Amiga.
> 
> There is a reason why kernel supports modules or do you suggest "modules
> provide little to no practical benefit today" and let's just have
> everything built-in or disabled.
> 

Right, maybe that is a too bold statement. Probably it could be 
rephrased to:

"While maintaining a modular IPv6 stack still offers footprint savings 
for specific setups, this benefit is outweighed by the architectural 
burden it imposes on the rest of the kernel."

I believe that having modules is useful. I just do not think it pays off 
here.

On Mon, 2026-03-09 at 11:22 +0100, Krzysztof Kozlowski wrote:
> On 09/03/2026 03:19, Fernando Fernandez Mancera wrote:
> > Historically, the Linux kernel has supported compiling the IPv6 stack as
> > a loadable module. While this made sense in the early days of IPv6
> > adoption, modern deployments and distributions overwhelmingly either
> > build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
> > entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
> > no practical benefit today.
> 
> It does. We all use generic kernels, thus it is one configuration for
> all boards and some setups have IPv6 and some not. The ones without IPv6
> just don't use that module.
> 
> Also, with these generic kernels (so again all machines are using same
> ones, e.g. distro) users can easily blacklist the module.

Perhaps it's time for CONFIG_LEGACY_IP to be buildable as a module
instead, in preparation for its deprecation?

On 09/03/2026 11:22, Krzysztof Kozlowski wrote:
> On 09/03/2026 03:19, Fernando Fernandez Mancera wrote:
>> Historically, the Linux kernel has supported compiling the IPv6 stack as
>> a loadable module. While this made sense in the early days of IPv6
>> adoption, modern deployments and distributions overwhelmingly either
>> build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
>> entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
>> no practical benefit today.
> 
> It does. We all use generic kernels, thus it is one configuration for
> all boards and some setups have IPv6 and some not. The ones without IPv6
> just don't use that module.
> 
> Also, with these generic kernels (so again all machines are using same
> ones, e.g. distro) users can easily blacklist the module.
> 

Heh, I just checked, that's 6 MB module on arm64 which apparently you
want to put into the kernel! That's not acceptable. We strive to use
generic kernels also on very small machines, which are both storage and
CPU limited (CPU time needed to load additional 6 MB of image file).

Best regards,
Krzysztof

On Mon, 9 Mar 2026 11:26:08 +0100 Krzysztof Kozlowski wrote:
> Heh, I just checked, that's 6 MB module on arm64 which apparently you
> want to put into the kernel!

Pretty sure you get 6MB because you have DEBUG_INFO enabled?
IMO "I have full debug info but I care about kernel size" is
internally inconsistent.

Here is the top line of bloatometer without debug info:

  add/remove: 1769/7 grow/shrink: 86/0 up/down: 374521/-228 (374293)

The vmlinux increases by 200kB with IPv6 built in.
Not a very dramatic increase.

Please note that opening any dual-stack socket will cause the IPv6
module to get loaded. And opening a dual-stack socket will fail if 
IPv6 is blacklisted. So I find it quite hard to believe that other
that deeply embedded systems with custom configs there are systems
out there which don't end up with IPv6 loaded. Whether they have 
a single IPv6 address configured or not.

And if we stop supporting =m we can actually turn a bunch of indirect
calls into static inlines so in practice the memory use on real system
will be lower! 

Please be reasonable, this is objectively the right move.

On 10/03/2026 00:18, Jakub Kicinski wrote:
> On Mon, 9 Mar 2026 11:26:08 +0100 Krzysztof Kozlowski wrote:
>> Heh, I just checked, that's 6 MB module on arm64 which apparently you
>> want to put into the kernel!
> 
> Pretty sure you get 6MB because you have DEBUG_INFO enabled?

Yeah, that was defconfig with KASAN, not full debug info. defconfig
comes with deduced debug info.  In one of other email threads I
corrected that actual size on distro kernel is much smaller, e.g.
200-400 kB depending on arch or distro settings.

> IMO "I have full debug info but I care about kernel size" is
> internally inconsistent.

My argument is that many of arm64 devices I work with have fixed
partition sizes, come with their own bootloader which uses separate
fixed-size boot partition. I still want to be able to load arm64
defconfig into that boot partition. If it does not fit, I need to tweak
defconfig, e.g. disable some options.

I find it valid usecase and I was disagreeing here with that cloud-only
or big-machines-only approach.

> 
> Here is the top line of bloatometer without debug info:
> 
>   add/remove: 1769/7 grow/shrink: 86/0 up/down: 374521/-228 (374293)
> 
> The vmlinux increases by 200kB with IPv6 built in.
> Not a very dramatic increase.
> 
> Please note that opening any dual-stack socket will cause the IPv6
> module to get loaded. And opening a dual-stack socket will fail if 
> IPv6 is blacklisted. So I find it quite hard to believe that other
> that deeply embedded systems with custom configs there are systems
> out there which don't end up with IPv6 loaded. Whether they have 
> a single IPv6 address configured or not.

Yes, Ubuntu for that reasons does not have it even as module.

This should be used as *the* argument for these changes.

> 
> And if we stop supporting =m we can actually turn a bunch of indirect
> calls into static inlines so in practice the memory use on real system
> will be lower! 
> 
> Please be reasonable, this is objectively the right move.

I am very reasonable, just need to hear reasons. Just to remind - none
of the machines I have, none of the routers, none of the mobile phones
on 4G and 5G receive IPv6 so they don't actually need it. Not having
IPv6 built-in is therefore a valid use case.

Best regards,
Krzysztof

On Tue, 10 Mar 2026 21:02:40 +0100 Krzysztof Kozlowski wrote:
> > Here is the top line of bloatometer without debug info:
> > 
> >   add/remove: 1769/7 grow/shrink: 86/0 up/down: 374521/-228 (374293)
> > 
> > The vmlinux increases by 200kB with IPv6 built in.
> > Not a very dramatic increase.
> > 
> > Please note that opening any dual-stack socket will cause the IPv6
> > module to get loaded. And opening a dual-stack socket will fail if 
> > IPv6 is blacklisted. So I find it quite hard to believe that other
> > that deeply embedded systems with custom configs there are systems
> > out there which don't end up with IPv6 loaded. Whether they have 
> > a single IPv6 address configured or not.  
> 
> Yes, Ubuntu for that reasons does not have it even as module.
> 
> This should be used as *the* argument for these changes.

Completely fair, the submission is severely lacking in motivation 
and impact analysis :(

On 3/10/26 10:42 PM, Jakub Kicinski wrote:
> On Tue, 10 Mar 2026 21:02:40 +0100 Krzysztof Kozlowski wrote:
>>> Here is the top line of bloatometer without debug info:
>>>
>>>    add/remove: 1769/7 grow/shrink: 86/0 up/down: 374521/-228 (374293)
>>>
>>> The vmlinux increases by 200kB with IPv6 built in.
>>> Not a very dramatic increase.
>>>
>>> Please note that opening any dual-stack socket will cause the IPv6
>>> module to get loaded. And opening a dual-stack socket will fail if
>>> IPv6 is blacklisted. So I find it quite hard to believe that other
>>> that deeply embedded systems with custom configs there are systems
>>> out there which don't end up with IPv6 loaded. Whether they have
>>> a single IPv6 address configured or not.
>>
>> Yes, Ubuntu for that reasons does not have it even as module.
>>
>> This should be used as *the* argument for these changes.
> 
> Completely fair, the submission is severely lacking in motivation
> and impact analysis :(
> 

Yes it is. Sorry. I did handle that partially on v2 but will included as 
much arguments as possible in v3 and greater.

Thanks,
Fernando.

On Mon,  9 Mar 2026 03:19:33 +0100 Fernando Fernandez Mancera wrote:
> Historically, the Linux kernel has supported compiling the IPv6 stack as
> a loadable module. While this made sense in the early days of IPv6
> adoption, modern deployments and distributions overwhelmingly either
> build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
> entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
> no practical benefit today.

Have you tested this? Every single VM config we have in CI dies with:

[    0.774671][    T1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000187: 0000 [#1] SMP KASAN
[    0.775165][    T1] KASAN: null-ptr-deref in range [0x0000000000000c38-0x0000000000000c3f]
[    0.775165][    T1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc2-virtme #1 PREEMPT(full) 
[    0.775165][    T1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[    0.775165][    T1] RIP: 0010:ipv6_add_dev+0x32/0x1e0
[    0.775165][    T1] Code: fb 48 83 ec 08 e8 0e 48 a8 ff 85 c0 0f 84 65 01 00 00 48 8d bb 39 0c 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 54 01 00 00
[    0.775165][    T1] RSP: 0018:ffa0000000017d10 EFLAGS: 00010216
[    0.775165][    T1] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001
[    0.775165][    T1] RDX: 0000000000000187 RSI: 0000000000000008 RDI: 0000000000000c39
[    0.775165][    T1] RBP: 0000000000000100 R08: ffffffffa3eed8dc R09: fffffbfff4f10288
[    0.775165][    T1] R10: fffffbfff4f10289 R11: 0000000000000001 R12: dffffc0000000000
[    0.775165][    T1] R13: dffffc0000000000 R14: ff11000001f1cc00 R15: ffffffffa8216a90
[    0.775165][    T1] FS:  0000000000000000(0000) GS:ff1100008707a000(0000) knlGS:0000000000000000
[    0.775165][    T1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.775165][    T1] CR2: ff11000036a1e000 CR3: 000000003453b001 CR4: 0000000000771ef0
[    0.775165][    T1] PKRU: 55555554
[    0.775165][    T1] Call Trace:
[    0.775165][    T1]  <TASK>
[    0.775165][    T1]  addrconf_init+0xa9/0x160
[    0.775165][    T1]  inet6_init+0x287/0x410
[    0.775165][    T1]  do_one_initcall+0xd7/0x4a0
[    0.775165][    T1]  ? trace_event_raw_event_initcall_level+0x210/0x210
[    0.775165][    T1]  ? __kmalloc_noprof+0x2c5/0x730
[    0.775165][    T1]  kernel_init_freeable+0x57d/0x620
[    0.775165][    T1]  ? rest_init+0x200/0x200
[    0.775165][    T1]  kernel_init+0x1e/0x170
[    0.775165][    T1]  ? _raw_spin_unlock_irq+0x33/0x50
[    0.775165][    T1]  ret_from_fork+0x472/0x6b0
[    0.775165][    T1]  ? arch_exit_to_user_mode_prepare.isra.0+0x140/0x140
[    0.775165][    T1]  ? __switch_to+0x538/0xcf0
[    0.775165][    T1]  ? rest_init+0x200/0x200
[    0.775165][    T1]  ret_from_fork_asm+0x11/0x20
[    0.775165][    T1]  </TASK>
[    0.775165][    T1] Modules linked in:
[    0.816998][    T1] ---[ end trace 0000000000000000 ]---
[    0.818082][    T1] RIP: 0010:ipv6_add_dev+0x32/0x1e0
[    0.819103][    T1] Code: fb 48 83 ec 08 e8 0e 48 a8 ff 85 c0 0f 84 65 01 00 00 48 8d bb 39 0c 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 54 01 00 00
[    0.822985][    T1] RSP: 0018:ffa0000000017d10 EFLAGS: 00010216
[    0.824176][    T1] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001
[    0.825749][    T1] RDX: 0000000000000187 RSI: 0000000000000008 RDI: 0000000000000c39
[    0.827317][    T1] RBP: 0000000000000100 R08: ffffffffa3eed8dc R09: fffffbfff4f10288
[    0.828892][    T1] R10: fffffbfff4f10289 R11: 0000000000000001 R12: dffffc0000000000
[    0.830460][    T1] R13: dffffc0000000000 R14: ff11000001f1cc00 R15: ffffffffa8216a90
[    0.832037][    T1] FS:  0000000000000000(0000) GS:ff1100008707a000(0000) knlGS:0000000000000000
[    0.833800][    T1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.835095][    T1] CR2: ff11000036a1e000 CR3: 000000003453b001 CR4: 0000000000771ef0
[    0.836670][    T1] PKRU: 55555554
[    0.837358][    T1] Kernel panic - not syncing: Fatal exception
[    0.838351][    T1] ---[ end Kernel panic - not syncing: Fatal exception ]---

On 3/9/26 3:47 PM, Jakub Kicinski wrote:
> On Mon,  9 Mar 2026 03:19:33 +0100 Fernando Fernandez Mancera wrote:
>> Historically, the Linux kernel has supported compiling the IPv6 stack as
>> a loadable module. While this made sense in the early days of IPv6
>> adoption, modern deployments and distributions overwhelmingly either
>> build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
>> entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
>> no practical benefit today.
> 
> Have you tested this? Every single VM config we have in CI dies with:
> 

Hi Jakub,

I did and I just booted a VM with the series. I just discovered that it 
dies with virtme-ng. Changing the fs_initcall() to device_initcall() 
fixes it so this is likely a race condition.. probably due to loopback?

Sorry about the noise. I do not understand why this didn't happen on my 
libvirt setup but it did happen on virtme-ng.

Well, if there is consensus that we want to go ahead with this, I will 
address this on the V2.

Thanks for letting me know.
Fernando.

> [    0.774671][    T1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000187: 0000 [#1] SMP KASAN
> [    0.775165][    T1] KASAN: null-ptr-deref in range [0x0000000000000c38-0x0000000000000c3f]
> [    0.775165][    T1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc2-virtme #1 PREEMPT(full)
> [    0.775165][    T1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [    0.775165][    T1] RIP: 0010:ipv6_add_dev+0x32/0x1e0
> [    0.775165][    T1] Code: fb 48 83 ec 08 e8 0e 48 a8 ff 85 c0 0f 84 65 01 00 00 48 8d bb 39 0c 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 54 01 00 00
> [    0.775165][    T1] RSP: 0018:ffa0000000017d10 EFLAGS: 00010216
> [    0.775165][    T1] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001
> [    0.775165][    T1] RDX: 0000000000000187 RSI: 0000000000000008 RDI: 0000000000000c39
> [    0.775165][    T1] RBP: 0000000000000100 R08: ffffffffa3eed8dc R09: fffffbfff4f10288
> [    0.775165][    T1] R10: fffffbfff4f10289 R11: 0000000000000001 R12: dffffc0000000000
> [    0.775165][    T1] R13: dffffc0000000000 R14: ff11000001f1cc00 R15: ffffffffa8216a90
> [    0.775165][    T1] FS:  0000000000000000(0000) GS:ff1100008707a000(0000) knlGS:0000000000000000
> [    0.775165][    T1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    0.775165][    T1] CR2: ff11000036a1e000 CR3: 000000003453b001 CR4: 0000000000771ef0
> [    0.775165][    T1] PKRU: 55555554
> [    0.775165][    T1] Call Trace:
> [    0.775165][    T1]  <TASK>
> [    0.775165][    T1]  addrconf_init+0xa9/0x160
> [    0.775165][    T1]  inet6_init+0x287/0x410
> [    0.775165][    T1]  do_one_initcall+0xd7/0x4a0
> [    0.775165][    T1]  ? trace_event_raw_event_initcall_level+0x210/0x210
> [    0.775165][    T1]  ? __kmalloc_noprof+0x2c5/0x730
> [    0.775165][    T1]  kernel_init_freeable+0x57d/0x620
> [    0.775165][    T1]  ? rest_init+0x200/0x200
> [    0.775165][    T1]  kernel_init+0x1e/0x170
> [    0.775165][    T1]  ? _raw_spin_unlock_irq+0x33/0x50
> [    0.775165][    T1]  ret_from_fork+0x472/0x6b0
> [    0.775165][    T1]  ? arch_exit_to_user_mode_prepare.isra.0+0x140/0x140
> [    0.775165][    T1]  ? __switch_to+0x538/0xcf0
> [    0.775165][    T1]  ? rest_init+0x200/0x200
> [    0.775165][    T1]  ret_from_fork_asm+0x11/0x20
> [    0.775165][    T1]  </TASK>
> [    0.775165][    T1] Modules linked in:
> [    0.816998][    T1] ---[ end trace 0000000000000000 ]---
> [    0.818082][    T1] RIP: 0010:ipv6_add_dev+0x32/0x1e0
> [    0.819103][    T1] Code: fb 48 83 ec 08 e8 0e 48 a8 ff 85 c0 0f 84 65 01 00 00 48 8d bb 39 0c 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 54 01 00 00
> [    0.822985][    T1] RSP: 0018:ffa0000000017d10 EFLAGS: 00010216
> [    0.824176][    T1] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001
> [    0.825749][    T1] RDX: 0000000000000187 RSI: 0000000000000008 RDI: 0000000000000c39
> [    0.827317][    T1] RBP: 0000000000000100 R08: ffffffffa3eed8dc R09: fffffbfff4f10288
> [    0.828892][    T1] R10: fffffbfff4f10289 R11: 0000000000000001 R12: dffffc0000000000
> [    0.830460][    T1] R13: dffffc0000000000 R14: ff11000001f1cc00 R15: ffffffffa8216a90
> [    0.832037][    T1] FS:  0000000000000000(0000) GS:ff1100008707a000(0000) knlGS:0000000000000000
> [    0.833800][    T1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    0.835095][    T1] CR2: ff11000036a1e000 CR3: 000000003453b001 CR4: 0000000000771ef0
> [    0.836670][    T1] PKRU: 55555554
> [    0.837358][    T1] Kernel panic - not syncing: Fatal exception
> [    0.838351][    T1] ---[ end Kernel panic - not syncing: Fatal exception ]---