On 12.5.2022. 14:48, Claudio Jeker wrote:
> I think the diff below may be enough to fix this issue. It drops the SMR
> critical secition around the enqueue operation but uses a reference on the
> port insteadt to ensure that the device can't be removed during the
> enqueue. Once the enqueue is finished we enter the SMR critical section
> again and drop the reference.
>
> To make it clear that the SMR_TAILQ remains intact while a refcount is
> held I moved refcnt_finalize() above SMR_TAILQ_REMOVE_LOCKED(). This is
> not strictly needed since the next pointer remains valid up until the
> smr_barrier() call but I find this a bit easier to understand.
> First make sure nobody else holds a reference then remove the port from
> the list.
>
> I currently have no test setup to verify this but I hope someone else can
> give this a spin.
Hi,
for now veb seems stable and i can't panic box although it should, but
please give me few more hours to torture it properly.
I'm doing this in loop
ifconfig veb1 destroy
sh /etc/netstart
ifconfig veb0 destroy
sh /etc/netstart
ifconfig vport1 destroy
sh /etc/netstart
ifconfig vport0 destroy
sh /etc/netstart
my config
veb1: flags=a843<UP,BROADCAST,RUNNING,SIMPLEX,LINK1,MULTICAST>
index 25 llprio 3
groups: veb
ix1 flags=3<LEARNING,DISCOVER>
port 2 ifpriority 0 ifcost 0
vport1 flags=3<LEARNING,DISCOVER>
port 27 ifpriority 0 ifcost 0
veb0: flags=a843<UP,BROADCAST,RUNNING,SIMPLEX,LINK1,MULTICAST>
index 26 llprio 3
groups: veb
ix0 flags=3<LEARNING,DISCOVER>
port 1 ifpriority 0 ifcost 0
vport0 flags=3<LEARNING,DISCOVER>
port 28 ifpriority 0 ifcost 0
ix2 flags=100<SPAN>
vport1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
lladdr ec:f4:bb:da:f7:fa
index 27 priority 0 llprio 3
groups: vport
inet 192.168.111.11 netmask 0xffffff00 broadcast 192.168.111.255
vport0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
lladdr ec:f4:bb:da:f7:f8
index 28 priority 0 llprio 3
groups: vport
inet 192.168.100.11 netmask 0xffffff00 broadcast 192.168.100.255
