By adding the following code right after process dispatch in the main loop,
the crash is fixed.
So I think the condition mentioned above is a rare but valid case.
A ctrl process node being scheduled adds a packet (pending frame) to a node
and the packet is referring to an interface which will be
Hi list,
During the test, when l3sub if is deleted, I got a new abort in interface
drop node, seems the packet reference to a deleted interface.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1 0x7face8d17859 in __GI_abort () at abort.c:79
> #2
The crash have not been found anymore.
Does this fix make any sense? it it does, I will submit a patch later.
Zhang Dongya via lists.fd.io 于
2022年11月29日周二 22:51写道：
> Hi ben,
>
> In the beginning I also think it should be a barrier issue, however it
> turned out not the case.
>
> The pkt which
Hi ben,
In the beginning I also think it should be a barrier issue, however it
turned out not the case.
The pkt which had sw_if_index[VLIB_RX] set as the to-be-deleted interface
is actually being put to ip4-lookup node by my process node, the process
node add pkt in a timer drive way.
Since the
Hi Zhang,
I'd expect the interface deletion to happen under the worker barrier. VPP
workers should drain all their in-flight packets before entering the barrier,
so it should not be possible for the interface to disappear between your node
and ip4-lookup. Or am I missing something?
What I have
I have found a solution and it can solve the crash issue.
In ip4_sw_interface_add_del which is a callback for interface deletion, we
may set the fib index of the removed interface to 0 (default fib) instead
of ~0. This behavior is same with interface creation.
Zhang Dongya via lists.fd.io
Hi list,
Recently I encountered a vpp crash with my plugin enabled, after some
investigation I find it may related with l3 sub interface delete while my
process node add work to ip4-lookup node.
Intuitively I think it may related to a barrier usage but I tried to fix by
add some check in my
