Hello Hrvoje,
thank you for testing.
On Wed, May 11, 2022 at 10:40:28AM +0200, Hrvoje Popovski wrote:
> On 10.5.2022. 22:55, Alexander Bluhm wrote:
> > Yes. It is similar.
> >
> > I have read the whole mail thread and the final fix got commited.
> > But it looks incomplete, pf is still sleeping.
> >
> > Hrvoje, can you run the tests again that triggered the panics a
> > year ago?
>
> Hi,
>
> year ago panics was triggered when veb or tpmr bridged traffic. I've
> tried that right now and I couldn't trigger that panics.
> If I put vport and route traffic over veb than I can trigger panic with
> or without vlans as child-iface for veb.
> For panic i need to have pf enabled and to run
> ifconfig veb destroy or ifconfig vlan destroy and sh netstart in loop.
>
>
> this is panic without vlans
>
> ddb{4}> show all locks
> CPU 4:
> exclusive sched_lock &sched_lock r = 0 (0xffffffff824819c0)
> #0 witness_lock+0x311
> #1 sleep_setup+0xa5
> #2 rw_enter+0x211
> #3 pf_test+0xcf0
> #4 ip_output+0x6b7
> #5 ip_forward+0x2da
> #6 ip_input_if+0x353
> #7 ipv4_input+0x39
> #8 ether_input+0x3ad
> #9 vport_if_enqueue+0x19
> #10 veb_port_input+0x529
I suspect we deal with broadcast and this time things start
to go downhill here in veb_broadcast():
875 smr_read_enter();
876 SMR_TAILQ_FOREACH(tp, &sc->sc_ports.l_list, p_entry) {
877 if (rp == tp || (rp->p_protected & tp->p_protected)) {
878 /*
879 * don't let Ethernet packets hairpin or
880 * move between ports in the same protected
881 * domain(s).
882 */
883 continue;
884 }
885
886 ifp0 = tp->p_ifp0;
887 if (!ISSET(ifp0->if_flags, IFF_RUNNING)) {
888 /* don't waste time */
889 continue;
890 }
891
892 if (!ISSET(tp->p_bif_flags, IFBIF_DISCOVER) &&
893 !ISSET(m0->m_flags, M_BCAST | M_MCAST)) {
894 /* don't flood unknown unicast */
895 continue;
896 }
897
898 if (veb_rule_filter(tp, VEB_RULE_LIST_OUT, m0, src, dst))
899 continue;
900
901 m = m_dup_pkt(m0, max_linkhdr + ETHER_ALIGN, M_NOWAIT);
902 if (m == NULL) {
903 /* XXX count error? */
904 continue;
905 }
906
907 (*tp->p_enqueue)(ifp0, m); /* XXX count error */
908 }
909 smr_read_leave();
the veb_broadcast() is being called from veb_port_input():
1082
1083 /* unknown unicast address */
1084 } else {
1085 SET(m->m_flags, ETH64_IS_BROADCAST(dst) ? M_BCAST :
M_MCAST);
1086 }
1087
1088 veb_broadcast(sc, p, m, src, dst);
1089 return (NULL);
I think I've spotted the place yesterday night in code, but could not
figure out how to wire things up to trigger the panic. Fortunately you've
managed to figure it out.
I think vport_if_enqueue() is a trap/land mine here. The function should really
be queueing a packet instead of dispatching it right away.
thanks and
regards
sashan
