[EVL] Kernel WARNING: notifier callback netevent_handler already registered

[EVL] Kernel WARNING: notifier callback netevent_handler already registered

[Hannes Diethelm]

Hello

There is a Kernel WARNING: "notifier callback netevent_handler already registered right after boot". It is repeated 5 times.

Config:
Debian Trixie with xfce4 Desktop
libevl: r56
linux-evl: v6.12.67-evl2-rebase

I traced the issue already trough the following code:
net/core/net_namespace.c:355
kernel/evl/net/net.c:35
kernel/evl/net/ipv4/ipv4.c:41
kernel/evl/net/ipv4/arp.c:323

However, I lack the knowledge to do a proper fix. One way would be to just check in evl_net_init_arp() if it is already
registered and don't do it more than once but that doesn't feel right.

Some background: I am working on integrating Xenomai3/4 into LinuxCNC. Due to this, I have a full desktop running with a
Xenomai kernel. Probably one of the installed applications triggers this issue.

It is just a hobby and I am not an official maintainer of LinuxCNC but if it works well, it might get merged.

Regards
Hannes

Full warning, one of 5 but they are all equal:

[    4.158674] ------------[ cut here ]------------
[    4.158680] notifier callback netevent_handler already registered
[    4.158716] WARNING: CPU: 15 PID: 1095 at kernel/notifier.c:31 notifier_chain_register+0x3e/0xb0
[    4.158736] Modules linked in: binfmt_misc intel_rapl_msr intel_rapl_common ccp kvm irqbypass crct10dif_pclmul ghash_clmulni_intel snd_hda_codec_generic sha512_ssse3 sha256_ssse3 sha1_ssse3 snd_hda_intel aesni_intel snd_intel_dspcfg snd_intel_sdw_acpi gf128mul snd_hda_codec crypto_simd cryptd pcspkr snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore evdev sg parport_pc ppdev lp parport efi_pstore configfs nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci qemu_fw_cfg virtio_rng ip_tables x_tables autofs4 ext4 crc32c_generic crc16 mbcache jbd2 virtio_gpu virtio_dma_buf drm_shmem_helper sr_mod drm_kms_helper cdrom iTCO_wdt intel_pmc_bxt xhci_pci iTCO_vendor_support watchdog xhci_hcd ahci libahci drm crc32_pclmul usbcore crc32c_intel virtio_blk libata psmouse virtio_net net_failover serio_raw failover usb_common scsi_mod i2c_i801 lpc_ich i2c_smbus scsi_common button
[    4.158773] CPU: 15 UID: 0 PID: 1095 Comm: (crub_all) Not tainted 6.12.67-xenomai4-53a3aa #3
[    4.158777] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[    4.158778] IRQ stage: Linux
[    4.158781] RIP: 0010:notifier_chain_register+0x3e/0xb0
[    4.158784] Code: 10 7f 33 75 04 84 d2 75 7d 48 8d 78 08 48 8b 40 08 48 85 c0 74 20 48 39 c6 75 e0 48 8b 36 48 c7 c7 98 e1 54 9f e8 b2 28 fc ff <0f> 0b b8 ef ff ff ff c3 cc cc cc cc 48 89 46 08 48 89 37 66 90 31
[    4.158785] RSP: 0018:ffffc91b414e7d00 EFLAGS: 00010282
[    4.158789] RAX: 0000000000000000 RBX: ffffffffa090b240 RCX: 0000000000000027
[    4.158793] RDX: ffff8901efda0948 RSI: 0000000000000001 RDI: ffff8901efda0940
[    4.158794] RBP: ffffffff9fe809c0 R08: 0000000000000a74 R09: 0000000000000000
[    4.158794] R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff9fc5a3e0
[    4.158795] R13: 0000000000000000 R14: ffffffff9fc528ec R15: ffffc91b414e7d58
[    4.158797] FS:  00007f16c63765c0(0000) GS:ffff8901efd80000(0000) knlGS:0000000000000000
[    4.158801] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    4.158802] CR2: 00007f16c719f160 CR3: 000000010491c000 CR4: 0000000000750ef0
[    4.158803] PKRU: 55555554
[    4.158803] Call Trace:
[    4.158815]  <TASK>
[    4.158816]  atomic_notifier_chain_register+0x24/0x40
[    4.158820]  evl_net_init_arp+0x3f/0x50
[    4.158830]  evl_net_init_ipv4+0x2a/0x100
[    4.158833]  setup_net+0x9e/0x2b0
[    4.158858]  copy_net_ns+0x111/0x270
[    4.158861]  create_new_namespaces+0x113/0x2e0
[    4.158865]  unshare_nsproxy_namespaces+0x58/0xa0
[    4.158868]  ksys_unshare+0x17d/0x400
[    4.158887]  __x64_sys_unshare+0x12/0x20
[    4.158890]  do_syscall_64+0xc0/0x230
[    4.158913]  ? syscall_exit_to_user_mode+0x1da/0x1f0
[    4.158916]  ? do_syscall_64+0xcc/0x230
[    4.158917]  ? do_user_addr_fault+0x4c1/0x750
[    4.158926]  ? __ct_user_enter+0x29/0xd0
[    4.158927]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[    4.158949] RIP: 0033:0x7f16c6ebe967
[    4.158960] Code: 73 01 c3 48 8b 0d a9 34 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 10 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 79 34 0d 00 f7 d8 64 89 01 48
[    4.158961] RSP: 002b:00007ffe188cc308 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
[    4.158962] RAX: ffffffffffffffda RBX: 00007ffe188cc8c8 RCX: 00007f16c6ebe967
[    4.158962] RDX: 0000000000000000 RSI: 00007ffe188cc270 RDI: 0000000040000000
[    4.158963] RBP: 00007ffe188cc350 R08: 0000000000000000 R09: 0000000000000000
[    4.158963] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000040000000
[    4.158967] R13: 00000000fffffff5 R14: 00007f16c7374380 R15: 00000000fffffff5
[    4.158969]  </TASK>
[    4.158969] ---[ end trace 0000000000000000 ]---

Re: [EVL] Kernel WARNING: notifier callback netevent_handler already registered

[Philippe Gerum]

Hannes Diethelm <hannes.diethelm@gmail.com> writes:

> Hello
>
> There is a Kernel WARNING: "notifier callback netevent_handler already registered right after boot". It is repeated 5 times.
>
> Config:
> Debian Trixie with xfce4 Desktop
> libevl: r56
> linux-evl: v6.12.67-evl2-rebase
>
> I traced the issue already trough the following code:
> net/core/net_namespace.c:355
> kernel/evl/net/net.c:35
> kernel/evl/net/ipv4/ipv4.c:41
> kernel/evl/net/ipv4/arp.c:323
>
> However, I lack the knowledge to do a proper fix. One way would be to just check in evl_net_init_arp() if it is already
> registered and don't do it more than once but that doesn't feel right.

It looks like the system is instantiating multiple network namespaces,
for each of which we set up an ARP front cache by calling
evl_net_init_arp(). Bad idea to hook a system-wide handler there as
well. Could you confirm this fix [1] works for you?

Thanks for reporting this.

[1] https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commit/569beef061321c2c00d775b13ad0aec1a1d2a416

-- 
Philippe.

Re: [EVL] Kernel WARNING: notifier callback netevent_handler already registered

[Hannes Diethelm]

Am 25.04.26 um 20:50 schrieb Philippe Gerum:
> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
> 
>> Hello
>>
>> There is a Kernel WARNING: "notifier callback netevent_handler already registered right after boot". It is repeated 5 times.
>>
>> Config:
>> Debian Trixie with xfce4 Desktop
>> libevl: r56
>> linux-evl: v6.12.67-evl2-rebase
>>
>> I traced the issue already trough the following code:
>> net/core/net_namespace.c:355
>> kernel/evl/net/net.c:35
>> kernel/evl/net/ipv4/ipv4.c:41
>> kernel/evl/net/ipv4/arp.c:323
>>
>> However, I lack the knowledge to do a proper fix. One way would be to just check in evl_net_init_arp() if it is already
>> registered and don't do it more than once but that doesn't feel right.
> 
> It looks like the system is instantiating multiple network namespaces,
> for each of which we set up an ARP front cache by calling
> evl_net_init_arp(). Bad idea to hook a system-wide handler there as
> well. Could you confirm this fix [1] works for you?
> 
> Thanks for reporting this.
> 
> [1] https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commit/569beef061321c2c00d775b13ad0aec1a1d2a416
> 

Thanks, that was fast. The WARNING is gone now.

But now after just updating to the kernel including your fix, I have a different behavior on
incoming packages. It seams that the default when no filter is set has changed from EVL_RX_SKIP to EVL_RX_ACCEPT.

linux-evl: v6.12.67-evl2-rebase
-After evl net -ei enp7s0, I can ping another host.
-oob-net-icmp does only receive packages when I use an eBPF filter with EVL_RX_ACCEPT
-After that, ping doesn't work any more

linux-evl: v6.12.y-cip-evl-rebase
-After evl net -ei enp7s0, I can NOT ping another host.
-oob-net-icmp does receive packages
-If I use an eBPF filter returning EVL_RX_SKIP, I can ping again

I am not using VLAN's.

Was that changed on purpose?

Re: [EVL] Kernel WARNING: notifier callback netevent_handler already registered

[Philippe Gerum]

Hannes Diethelm <hannes.diethelm@gmail.com> writes:

> Am 25.04.26 um 20:50 schrieb Philippe Gerum:
>> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
>> 
>>> Hello
>>>
>>> There is a Kernel WARNING: "notifier callback netevent_handler already registered right after boot". It is repeated 5 times.
>>>
>>> Config:
>>> Debian Trixie with xfce4 Desktop
>>> libevl: r56
>>> linux-evl: v6.12.67-evl2-rebase
>>>
>>> I traced the issue already trough the following code:
>>> net/core/net_namespace.c:355
>>> kernel/evl/net/net.c:35
>>> kernel/evl/net/ipv4/ipv4.c:41
>>> kernel/evl/net/ipv4/arp.c:323
>>>
>>> However, I lack the knowledge to do a proper fix. One way would be to just check in evl_net_init_arp() if it is already
>>> registered and don't do it more than once but that doesn't feel right.
>> It looks like the system is instantiating multiple network
>> namespaces,
>> for each of which we set up an ARP front cache by calling
>> evl_net_init_arp(). Bad idea to hook a system-wide handler there as
>> well. Could you confirm this fix [1] works for you?
>> Thanks for reporting this.
>> [1]
>> https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commit/569beef061321c2c00d775b13ad0aec1a1d2a416
>> 
>
> Thanks, that was fast. The WARNING is gone now.
>
> But now after just updating to the kernel including your fix, I have a different behavior on
> incoming packages. It seams that the default when no filter is set has changed from EVL_RX_SKIP to EVL_RX_ACCEPT.
>
> linux-evl: v6.12.67-evl2-rebase
> -After evl net -ei enp7s0, I can ping another host.
> -oob-net-icmp does only receive packages when I use an eBPF filter with EVL_RX_ACCEPT
> -After that, ping doesn't work any more
>
> linux-evl: v6.12.y-cip-evl-rebase
> -After evl net -ei enp7s0, I can NOT ping another host.
> -oob-net-icmp does receive packages
> -If I use an eBPF filter returning EVL_RX_SKIP, I can ping again
>
> I am not using VLAN's.
>
> Was that changed on purpose?

Yes, this is implemented by this commit [1]. The rationale here is that
if you turn on the oob port directly on a base device, then the evl net
stack may assume that the device is entirely dedicated to oob traffic,
as opposed to enabling such port on some upper device based on the
former (e.g. a VLAN interface). As a result, all ingress traffic
received by such base device is diverted (RX_ACCEPT) to the evl net
stack.

[1] https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commit/3026e69cee2a1de047818fa06ad8c44623461a0d

-- 
Philippe.

Re: [EVL] Kernel WARNING: notifier callback netevent_handler already registered

[Hannes Diethelm]

Am 26.04.26 um 21:24 schrieb Philippe Gerum:
> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
> 
>> Am 25.04.26 um 20:50 schrieb Philippe Gerum:
>>> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
>>>
>>>> Hello
>>>>
>>>> There is a Kernel WARNING: "notifier callback netevent_handler already registered right after boot". It is repeated 5 times.
>>>>
>>>> Config:
>>>> Debian Trixie with xfce4 Desktop
>>>> libevl: r56
>>>> linux-evl: v6.12.67-evl2-rebase
>>>>
>>>> I traced the issue already trough the following code:
>>>> net/core/net_namespace.c:355
>>>> kernel/evl/net/net.c:35
>>>> kernel/evl/net/ipv4/ipv4.c:41
>>>> kernel/evl/net/ipv4/arp.c:323
>>>>
>>>> However, I lack the knowledge to do a proper fix. One way would be to just check in evl_net_init_arp() if it is already
>>>> registered and don't do it more than once but that doesn't feel right.
>>> It looks like the system is instantiating multiple network
>>> namespaces,
>>> for each of which we set up an ARP front cache by calling
>>> evl_net_init_arp(). Bad idea to hook a system-wide handler there as
>>> well. Could you confirm this fix [1] works for you?
>>> Thanks for reporting this.
>>> [1]
>>> https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commit/569beef061321c2c00d775b13ad0aec1a1d2a416
>>>
>>
>> Thanks, that was fast. The WARNING is gone now.
>>
>> But now after just updating to the kernel including your fix, I have a different behavior on
>> incoming packages. It seams that the default when no filter is set has changed from EVL_RX_SKIP to EVL_RX_ACCEPT.
>>
>> linux-evl: v6.12.67-evl2-rebase
>> -After evl net -ei enp7s0, I can ping another host.
>> -oob-net-icmp does only receive packages when I use an eBPF filter with EVL_RX_ACCEPT
>> -After that, ping doesn't work any more
>>
>> linux-evl: v6.12.y-cip-evl-rebase
>> -After evl net -ei enp7s0, I can NOT ping another host.
>> -oob-net-icmp does receive packages
>> -If I use an eBPF filter returning EVL_RX_SKIP, I can ping again
>>
>> I am not using VLAN's.
>>
>> Was that changed on purpose?
> 
> Yes, this is implemented by this commit [1]. The rationale here is that
> if you turn on the oob port directly on a base device, then the evl net
> stack may assume that the device is entirely dedicated to oob traffic,
> as opposed to enabling such port on some upper device based on the
> former (e.g. a VLAN interface). As a result, all ingress traffic
> received by such base device is diverted (RX_ACCEPT) to the evl net
> stack.
> 
> [1] https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commit/3026e69cee2a1de047818fa06ad8c44623461a0d
> 

This makes sense. It took me some time to get evl reading packages by 
activating an eBPF filter and it's mostly save to assume that you don't 
have mixed traffic on an real time network interface. With this change, 
a filter is not needed any more.

A bit off topic:

Is there anything like rtping for evl? I have seen oob-net-icmp.c but 
this is answering requests.

In Xenomai3, there is a debian package configuration. Any interest in 
one for libevl? I have one working but it's still very basic. If it's 
presentable, I can send a patch.

Re: [EVL] Kernel WARNING: notifier callback netevent_handler already registered

[Paul]

On Sat, 25 Apr 2026 18:24:14 +0200
Hannes Diethelm <hannes.diethelm@gmail.com> wrote:

> Some background: I am working on integrating Xenomai3/4 into
> LinuxCNC. Due to this, I have a full desktop running with a Xenomai
> kernel. Probably one of the installed applications triggers this
> issue.
> 
> It is just a hobby and I am not an official maintainer of LinuxCNC
> but if it works well, it might get merged.

Please, no.
Linuxcnc is so badly written, it is extremely difficult to debug. I use
it as en example of how not to write efficient code.

Re: [EVL] Kernel WARNING: notifier callback netevent_handler already registered

[Florian Bezdeka]

On Sun, 2026-04-26 at 23:32 +0200, Hannes Diethelm wrote:
> Am 26.04.26 um 21:24 schrieb Philippe Gerum:
> > Hannes Diethelm <hannes.diethelm@gmail.com> writes:
> > 
> > > Am 25.04.26 um 20:50 schrieb Philippe Gerum:
> > > > Hannes Diethelm <hannes.diethelm@gmail.com> writes:
> > > > 
> > > > > Hello
> > > > > 
> > > > > There is a Kernel WARNING: "notifier callback netevent_handler already registered right after boot". It is repeated 5 times.
> > > > > 
> > > > > Config:
> > > > > Debian Trixie with xfce4 Desktop
> > > > > libevl: r56
> > > > > linux-evl: v6.12.67-evl2-rebase
> > > > > 
> > > > > I traced the issue already trough the following code:
> > > > > net/core/net_namespace.c:355
> > > > > kernel/evl/net/net.c:35
> > > > > kernel/evl/net/ipv4/ipv4.c:41
> > > > > kernel/evl/net/ipv4/arp.c:323
> > > > > 
> > > > > However, I lack the knowledge to do a proper fix. One way would be to just check in evl_net_init_arp() if it is already
> > > > > registered and don't do it more than once but that doesn't feel right.
> > > > It looks like the system is instantiating multiple network
> > > > namespaces,
> > > > for each of which we set up an ARP front cache by calling
> > > > evl_net_init_arp(). Bad idea to hook a system-wide handler there as
> > > > well. Could you confirm this fix [1] works for you?
> > > > Thanks for reporting this.
> > > > [1]
> > > > https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commit/569beef061321c2c00d775b13ad0aec1a1d2a416
> > > > 
> > > 
> > > Thanks, that was fast. The WARNING is gone now.
> > > 
> > > But now after just updating to the kernel including your fix, I have a different behavior on
> > > incoming packages. It seams that the default when no filter is set has changed from EVL_RX_SKIP to EVL_RX_ACCEPT.
> > > 
> > > linux-evl: v6.12.67-evl2-rebase
> > > -After evl net -ei enp7s0, I can ping another host.
> > > -oob-net-icmp does only receive packages when I use an eBPF filter with EVL_RX_ACCEPT
> > > -After that, ping doesn't work any more
> > > 
> > > linux-evl: v6.12.y-cip-evl-rebase
> > > -After evl net -ei enp7s0, I can NOT ping another host.
> > > -oob-net-icmp does receive packages
> > > -If I use an eBPF filter returning EVL_RX_SKIP, I can ping again
> > > 
> > > I am not using VLAN's.
> > > 
> > > Was that changed on purpose?
> > 
> > Yes, this is implemented by this commit [1]. The rationale here is that
> > if you turn on the oob port directly on a base device, then the evl net
> > stack may assume that the device is entirely dedicated to oob traffic,
> > as opposed to enabling such port on some upper device based on the
> > former (e.g. a VLAN interface). As a result, all ingress traffic
> > received by such base device is diverted (RX_ACCEPT) to the evl net
> > stack.
> > 
> > [1] https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commit/3026e69cee2a1de047818fa06ad8c44623461a0d
> > 
> 
> This makes sense. It took me some time to get evl reading packages by 
> activating an eBPF filter and it's mostly save to assume that you don't 
> have mixed traffic on an real time network interface. With this change, 
> a filter is not needed any more.
> 
> A bit off topic:
> 
> Is there anything like rtping for evl? I have seen oob-net-icmp.c but 
> this is answering requests.
> 
> In Xenomai3, there is a debian package configuration. Any interest in 
> one for libevl? I have one working but it's still very basic. If it's 
> presentable, I can send a patch.

There is a debianization for x4 in xenomai-images already. See [1]. 
Can't tell why it hasn't been upstreamed yet. Maybe Tobias or Philippe
can comment on that.

[1] https://gitlab.com/Xenomai/xenomai-images/-/tree/master/recipes-xenomai/libevl/files/debian

Re: [EVL] Kernel WARNING: notifier callback netevent_handler already registered

[Hannes Diethelm]

Am 27.04.26 um 11:18 schrieb Florian Bezdeka:
> On Sun, 2026-04-26 at 23:32 +0200, Hannes Diethelm wrote:
>> Am 26.04.26 um 21:24 schrieb Philippe Gerum:
>>> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
>>>
>>>> Am 25.04.26 um 20:50 schrieb Philippe Gerum:
>>>>> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
>>>>>
>>>>>> Hello
>>>>>>
>>>>>> There is a Kernel WARNING: "notifier callback netevent_handler already registered right after boot". It is repeated 5 times.
>>>>>>
>>>>>> Config:
>>>>>> Debian Trixie with xfce4 Desktop
>>>>>> libevl: r56
>>>>>> linux-evl: v6.12.67-evl2-rebase
>>>>>>
>>>>>> I traced the issue already trough the following code:
>>>>>> net/core/net_namespace.c:355
>>>>>> kernel/evl/net/net.c:35
>>>>>> kernel/evl/net/ipv4/ipv4.c:41
>>>>>> kernel/evl/net/ipv4/arp.c:323
>>>>>>
>>>>>> However, I lack the knowledge to do a proper fix. One way would be to just check in evl_net_init_arp() if it is already
>>>>>> registered and don't do it more than once but that doesn't feel right.
>>>>> It looks like the system is instantiating multiple network
>>>>> namespaces,
>>>>> for each of which we set up an ARP front cache by calling
>>>>> evl_net_init_arp(). Bad idea to hook a system-wide handler there as
>>>>> well. Could you confirm this fix [1] works for you?
>>>>> Thanks for reporting this.
>>>>> [1]
>>>>> https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commit/569beef061321c2c00d775b13ad0aec1a1d2a416
>>>>>
>>>>
>>>> Thanks, that was fast. The WARNING is gone now.
>>>>
>>>> But now after just updating to the kernel including your fix, I have a different behavior on
>>>> incoming packages. It seams that the default when no filter is set has changed from EVL_RX_SKIP to EVL_RX_ACCEPT.
>>>>
>>>> linux-evl: v6.12.67-evl2-rebase
>>>> -After evl net -ei enp7s0, I can ping another host.
>>>> -oob-net-icmp does only receive packages when I use an eBPF filter with EVL_RX_ACCEPT
>>>> -After that, ping doesn't work any more
>>>>
>>>> linux-evl: v6.12.y-cip-evl-rebase
>>>> -After evl net -ei enp7s0, I can NOT ping another host.
>>>> -oob-net-icmp does receive packages
>>>> -If I use an eBPF filter returning EVL_RX_SKIP, I can ping again
>>>>
>>>> I am not using VLAN's.
>>>>
>>>> Was that changed on purpose?
>>>
>>> Yes, this is implemented by this commit [1]. The rationale here is that
>>> if you turn on the oob port directly on a base device, then the evl net
>>> stack may assume that the device is entirely dedicated to oob traffic,
>>> as opposed to enabling such port on some upper device based on the
>>> former (e.g. a VLAN interface). As a result, all ingress traffic
>>> received by such base device is diverted (RX_ACCEPT) to the evl net
>>> stack.
>>>
>>> [1] https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commit/3026e69cee2a1de047818fa06ad8c44623461a0d
>>>
>>
>> This makes sense. It took me some time to get evl reading packages by
>> activating an eBPF filter and it's mostly save to assume that you don't
>> have mixed traffic on an real time network interface. With this change,
>> a filter is not needed any more.
>>
>> A bit off topic:
>>
>> Is there anything like rtping for evl? I have seen oob-net-icmp.c but
>> this is answering requests.
>>
>> In Xenomai3, there is a debian package configuration. Any interest in
>> one for libevl? I have one working but it's still very basic. If it's
>> presentable, I can send a patch.
> 
> There is a debianization for x4 in xenomai-images already. See [1].
> Can't tell why it hasn't been upstreamed yet. Maybe Tobias or Philippe
> can comment on that.
> 
> [1] https://gitlab.com/Xenomai/xenomai-images/-/tree/master/recipes-xenomai/libevl/files/debian

Thanks for the hint. This debianization is also basic, looks like it is only built for
CI purpose. But it helps to improve my version.

There are a few things missing:
- Build dependency's
- Optional: evl group + udev rules to allow non-root usage
- Probably much more for being a install & use debian package

Re: [EVL] Kernel WARNING: notifier callback netevent_handler already registered

[Jan Kiszka]

On 16.05.26 10:48, Hannes Diethelm wrote:
> Am 27.04.26 um 11:18 schrieb Florian Bezdeka:
>> On Sun, 2026-04-26 at 23:32 +0200, Hannes Diethelm wrote:
>>> Am 26.04.26 um 21:24 schrieb Philippe Gerum:
>>>> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
>>>>
>>>>> Am 25.04.26 um 20:50 schrieb Philippe Gerum:
>>>>>> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> There is a Kernel WARNING: "notifier callback netevent_handler
>>>>>>> already registered right after boot". It is repeated 5 times.
>>>>>>>
>>>>>>> Config:
>>>>>>> Debian Trixie with xfce4 Desktop
>>>>>>> libevl: r56
>>>>>>> linux-evl: v6.12.67-evl2-rebase
>>>>>>>
>>>>>>> I traced the issue already trough the following code:
>>>>>>> net/core/net_namespace.c:355
>>>>>>> kernel/evl/net/net.c:35
>>>>>>> kernel/evl/net/ipv4/ipv4.c:41
>>>>>>> kernel/evl/net/ipv4/arp.c:323
>>>>>>>
>>>>>>> However, I lack the knowledge to do a proper fix. One way would
>>>>>>> be to just check in evl_net_init_arp() if it is already
>>>>>>> registered and don't do it more than once but that doesn't feel
>>>>>>> right.
>>>>>> It looks like the system is instantiating multiple network
>>>>>> namespaces,
>>>>>> for each of which we set up an ARP front cache by calling
>>>>>> evl_net_init_arp(). Bad idea to hook a system-wide handler there as
>>>>>> well. Could you confirm this fix [1] works for you?
>>>>>> Thanks for reporting this.
>>>>>> [1]
>>>>>> https://gitlab.com/Xenomai/xenomai4/linux-evl/-/
>>>>>> commit/569beef061321c2c00d775b13ad0aec1a1d2a416
>>>>>>
>>>>>
>>>>> Thanks, that was fast. The WARNING is gone now.
>>>>>
>>>>> But now after just updating to the kernel including your fix, I
>>>>> have a different behavior on
>>>>> incoming packages. It seams that the default when no filter is set
>>>>> has changed from EVL_RX_SKIP to EVL_RX_ACCEPT.
>>>>>
>>>>> linux-evl: v6.12.67-evl2-rebase
>>>>> -After evl net -ei enp7s0, I can ping another host.
>>>>> -oob-net-icmp does only receive packages when I use an eBPF filter
>>>>> with EVL_RX_ACCEPT
>>>>> -After that, ping doesn't work any more
>>>>>
>>>>> linux-evl: v6.12.y-cip-evl-rebase
>>>>> -After evl net -ei enp7s0, I can NOT ping another host.
>>>>> -oob-net-icmp does receive packages
>>>>> -If I use an eBPF filter returning EVL_RX_SKIP, I can ping again
>>>>>
>>>>> I am not using VLAN's.
>>>>>
>>>>> Was that changed on purpose?
>>>>
>>>> Yes, this is implemented by this commit [1]. The rationale here is that
>>>> if you turn on the oob port directly on a base device, then the evl net
>>>> stack may assume that the device is entirely dedicated to oob traffic,
>>>> as opposed to enabling such port on some upper device based on the
>>>> former (e.g. a VLAN interface). As a result, all ingress traffic
>>>> received by such base device is diverted (RX_ACCEPT) to the evl net
>>>> stack.
>>>>
>>>> [1] https://gitlab.com/Xenomai/xenomai4/linux-evl/-/
>>>> commit/3026e69cee2a1de047818fa06ad8c44623461a0d
>>>>
>>>
>>> This makes sense. It took me some time to get evl reading packages by
>>> activating an eBPF filter and it's mostly save to assume that you don't
>>> have mixed traffic on an real time network interface. With this change,
>>> a filter is not needed any more.
>>>
>>> A bit off topic:
>>>
>>> Is there anything like rtping for evl? I have seen oob-net-icmp.c but
>>> this is answering requests.
>>>
>>> In Xenomai3, there is a debian package configuration. Any interest in
>>> one for libevl? I have one working but it's still very basic. If it's
>>> presentable, I can send a patch.
>>
>> There is a debianization for x4 in xenomai-images already. See [1].
>> Can't tell why it hasn't been upstreamed yet. Maybe Tobias or Philippe
>> can comment on that.
>>
>> [1] https://gitlab.com/Xenomai/xenomai-images/-/tree/master/recipes-
>> xenomai/libevl/files/debian
> 
> Thanks for the hint. This debianization is also basic, looks like it is
> only built for
> CI purpose. But it helps to improve my version.
> 
> There are a few things missing:
> - Build dependency's

Which one? We are building the package in a clean sbuild env, so missing
build dependencies should have been revealed.

Note that Build-Depends is templated so that we could adjust it to
different libevl versions (not needed right now, though).

> - Optional: evl group + udev rules to allow non-root usage
> - Probably much more for being a install & use debian package
> 

Always open for patches to improve things. We might also move
debianization to libevl (like done for Xenomai 3) if that brings more
value to users.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [EVL] Kernel WARNING: notifier callback netevent_handler already registered

[Hannes Diethelm]

Am 16.05.26 um 11:50 schrieb Jan Kiszka:
> On 16.05.26 10:48, Hannes Diethelm wrote:
>> Am 27.04.26 um 11:18 schrieb Florian Bezdeka:
>>> On Sun, 2026-04-26 at 23:32 +0200, Hannes Diethelm wrote:
>>>> Am 26.04.26 um 21:24 schrieb Philippe Gerum:
>>>>> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
>>>>>
>>>>>> Am 25.04.26 um 20:50 schrieb Philippe Gerum:
>>>>>>> Hannes Diethelm <hannes.diethelm@gmail.com> writes:
>>>>>>>
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> There is a Kernel WARNING: "notifier callback netevent_handler
>>>>>>>> already registered right after boot". It is repeated 5 times.
>>>>>>>>
>>>>>>>> Config:
>>>>>>>> Debian Trixie with xfce4 Desktop
>>>>>>>> libevl: r56
>>>>>>>> linux-evl: v6.12.67-evl2-rebase
>>>>>>>>
>>>>>>>> I traced the issue already trough the following code:
>>>>>>>> net/core/net_namespace.c:355
>>>>>>>> kernel/evl/net/net.c:35
>>>>>>>> kernel/evl/net/ipv4/ipv4.c:41
>>>>>>>> kernel/evl/net/ipv4/arp.c:323
>>>>>>>>
>>>>>>>> However, I lack the knowledge to do a proper fix. One way would
>>>>>>>> be to just check in evl_net_init_arp() if it is already
>>>>>>>> registered and don't do it more than once but that doesn't feel
>>>>>>>> right.
>>>>>>> It looks like the system is instantiating multiple network
>>>>>>> namespaces,
>>>>>>> for each of which we set up an ARP front cache by calling
>>>>>>> evl_net_init_arp(). Bad idea to hook a system-wide handler there as
>>>>>>> well. Could you confirm this fix [1] works for you?
>>>>>>> Thanks for reporting this.
>>>>>>> [1]
>>>>>>> https://gitlab.com/Xenomai/xenomai4/linux-evl/-/
>>>>>>> commit/569beef061321c2c00d775b13ad0aec1a1d2a416
>>>>>>>
>>>>>>
>>>>>> Thanks, that was fast. The WARNING is gone now.
>>>>>>
>>>>>> But now after just updating to the kernel including your fix, I
>>>>>> have a different behavior on
>>>>>> incoming packages. It seams that the default when no filter is set
>>>>>> has changed from EVL_RX_SKIP to EVL_RX_ACCEPT.
>>>>>>
>>>>>> linux-evl: v6.12.67-evl2-rebase
>>>>>> -After evl net -ei enp7s0, I can ping another host.
>>>>>> -oob-net-icmp does only receive packages when I use an eBPF filter
>>>>>> with EVL_RX_ACCEPT
>>>>>> -After that, ping doesn't work any more
>>>>>>
>>>>>> linux-evl: v6.12.y-cip-evl-rebase
>>>>>> -After evl net -ei enp7s0, I can NOT ping another host.
>>>>>> -oob-net-icmp does receive packages
>>>>>> -If I use an eBPF filter returning EVL_RX_SKIP, I can ping again
>>>>>>
>>>>>> I am not using VLAN's.
>>>>>>
>>>>>> Was that changed on purpose?
>>>>>
>>>>> Yes, this is implemented by this commit [1]. The rationale here is that
>>>>> if you turn on the oob port directly on a base device, then the evl net
>>>>> stack may assume that the device is entirely dedicated to oob traffic,
>>>>> as opposed to enabling such port on some upper device based on the
>>>>> former (e.g. a VLAN interface). As a result, all ingress traffic
>>>>> received by such base device is diverted (RX_ACCEPT) to the evl net
>>>>> stack.
>>>>>
>>>>> [1] https://gitlab.com/Xenomai/xenomai4/linux-evl/-/
>>>>> commit/3026e69cee2a1de047818fa06ad8c44623461a0d
>>>>>
>>>>
>>>> This makes sense. It took me some time to get evl reading packages by
>>>> activating an eBPF filter and it's mostly save to assume that you don't
>>>> have mixed traffic on an real time network interface. With this change,
>>>> a filter is not needed any more.
>>>>
>>>> A bit off topic:
>>>>
>>>> Is there anything like rtping for evl? I have seen oob-net-icmp.c but
>>>> this is answering requests.
>>>>
>>>> In Xenomai3, there is a debian package configuration. Any interest in
>>>> one for libevl? I have one working but it's still very basic. If it's
>>>> presentable, I can send a patch.
>>>
>>> There is a debianization for x4 in xenomai-images already. See [1].
>>> Can't tell why it hasn't been upstreamed yet. Maybe Tobias or Philippe
>>> can comment on that.
>>>
>>> [1] https://gitlab.com/Xenomai/xenomai-images/-/tree/master/recipes-
>>> xenomai/libevl/files/debian
>>
>> Thanks for the hint. This debianization is also basic, looks like it is
>> only built for
>> CI purpose. But it helps to improve my version.
>>
>> There are a few things missing:
>> - Build dependency's
> 
> Which one? We are building the package in a clean sbuild env, so missing
> build dependencies should have been revealed.
> 
> Note that Build-Depends is templated so that we could adjust it to
> different libevl versions (not needed right now, though).
> 
Now I see it the templates. It makes it more flexible but makes it neccessary
to read into sbuild.
>> - Optional: evl group + udev rules to allow non-root usage
>> - Probably much more for being a install & use debian package
>>
> 
> Always open for patches to improve things. We might also move
> debianization to libevl (like done for Xenomai 3) if that brings more
> value to users.
> 
> Jan
> 
At least for me, having the debianization for xenomai3 helped a lot getting
all up and running.
I will create a patch when I have something presentable.

Regards
Hannes