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

[Hannes Diethelm <hannes.diethelm@gmail.com>]

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