On 24/11/20(Tue) 09:23, Pierre Emeriaud wrote: > > Trying to use mgre(4), I found what looks like a reliable way to crash > > the kernel which might be of interest. > > > > This machine is a one-month-old-current fairly light router, with inet > > default within rdomain 1. I will upgrade to a more recent snap > > shortly. > > I just upgraded to OpenBSD 6.8-current (GENERIC) #181: Mon Nov 23 > 20:55:15 MST 2020 and the same thing happens with vlan(4): > > $ doas ifconfig vlan12 inet 192.0.2.1/24 parent vio0 vnetid 12 > $ ifconfig vlan > vlan12: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > lladdr 02:00:00:ef:3d:d7 > index 8 priority 0 llprio 3 > encap: vnetid 12 parent vio0 txprio packet rxprio outer > groups: vlan > media: Ethernet autoselect > status: active > inet 192.0.2.1 netmask 0xffffff00 broadcast 192.0.2.255 > > $ doas route -T1 add 192.0.2.2/32 -link -iface vlan12
I wonder if the problem isn't in the validation of these parameters. Should we accept a L2 (-link) entry on a routing table which isn't the routing domain? If so why does the entry persist in the ARP cache? Can you reproduce the problem if you don't specify T1? > add host 192.0.2.2/32: gateway vlan12 > > $ route -T1 -n show -inet > Destination Gateway Flags Refs Use Mtu Prio Iface > 192.0.2.2 link#8 UHLS 0 0 - 8 vlan12 > > $ route -n show -inet > Internet: > Destination Gateway Flags Refs Use Mtu Prio Iface > 192.0.2/24 192.0.2.1 UCn 0 0 - 4 vlan12 > 192.0.2.1 02:00:00:ef:3d:d7 UHLl 0 0 - 1 vlan12 > 192.0.2.255 192.0.2.1 UHb 0 0 - 1 vlan12 > > $ doas ifconfig vlan12 down > $ doas ifconfig vlan12 destroy > > $ route -T1 -n show -inet > Destination Gateway Flags Refs Use Mtu Prio Iface > 192.0.2.2 link#8 UHLS 0 0 - 8 (null) > > $ doas route -T1 del 192.0.2.2/32 > > login: panic: kernel diagnostic assertion "ifp != NULL" failed: file > "/usr/src/sys/net/rtsock.c", line 975 > Stopped at db_enter+0x10: popq %rbp > TID PID UID PRFLAGS PFLAGS CPU COMMAND > *189431 84402 0 0x100003 0 0 route > db_enter() at db_enter+0x10 > panic(ffffffff81dcc1d7) at panic+0x12a > __assert(ffffffff81e32678,ffffffff81e40e69,3cf,ffffffff81d9f5fd) at > __assert+0x > 2b > rtm_output(ffff800000071480,ffff80000e77ce80,ffff80000e77cdd8,40,1) at > rtm_outp > ut+0x7ee > route_output(fffffd801ef36c00,fffffd801af0d698,0,0) at route_output+0x3c3 > route_usrreq(fffffd801af0d698,9,fffffd801ef36c00,0,0,ffff80000e720540) at > route > _usrreq+0x21a > sosend(fffffd801af0d698,0,ffff80000e77d0d8,0,0,0) at sosend+0x35b > dofilewritev(ffff80000e720540,3,ffff80000e77d0d8,0,ffff80000e77d1b0) at > dofilew > ritev+0x14d > sys_write(ffff80000e720540,ffff80000e77d150,ffff80000e77d1b0) at > sys_write+0x51 > > syscall(ffff80000e77d220) at syscall+0x315 > Xsyscall() at Xsyscall+0x128 > end of kernel > end trace frame: 0x7f7ffffd35b0, count: 4 > https://www.openbsd.org/ddb.html describes the minimum info required in bug > reports. Insufficient info makes it difficult to find and fix bugs. > ddb> >
