On Sun, Oct 30, 2016 at 10:33:43AM +0200, Dennis Lindroos wrote: > >Synopsis: vxlan(4) unaligned traps crashes on alpha > >Category: alpha > >Environment: > System : OpenBSD 6.0 > > Details : OpenBSD 6.0 (GENERIC) #469: Wed Jul 27 03:13:14 MDT > 2016 > [email protected]:/usr/src/sys/arch/alpha/compile/G > ENERIC > > Architecture: OpenBSD.alpha > Machine : alpha > >Description: > > Creating a vxlan(4) instance and setting an IPv6 address on it will > cause an unaligned access fault on alpha, tested on my DS10 and > DS15 systems. In OpenBSD 5.9, the crash happened only after e.g. a > ping6(8) like ff02::1%vxlan0... > > fatal kernel trap: > > trap entry = 0x4 (unaligned access fault) > a0 = 0xfffffc0037333e7e > a1 = 0x28 > a2 = 0x2 > pc = 0xfffffc00007efb70 > ra = 0xfffffc00007efb14 > curproc = 0xfffffc003fc70268 > pid = 8962, comm = ifconfig > > panic: trap > Stopped at Debugger+0x8: lda sp,10(sp) > TID PID UID PRFLAGS PFLAGS CPU COMMAND > * 8962 8962 0 0x3 0 0 ifconfig > Debugger(4, fffffc0000ced0d0, fffffd01fc0003fd, 8, 3, fffffc0000000008) at > Debugger+0x8 > panic(?, 28, 2, 4, fffffe0014cdf670, 8) at panic+0xcc > trap(?, ?, ?, ?, ?, 8) at trap+0x138 > XentUna(?, ?, ?, ?, ?, 8) at XentUna+0x20 > vxlan_output(?, 24, 2, fffffe0014cdfaa8, fffffe0014cdf8c8, 18) at > vxlan_output+0xa0 > vxlanstart(?, ?, 2, fffffe0014cdfaa8, fffffe0014cdf8c8, 18) at > vxlanstart+0x64 > ifq_dequeue(?, ?, 2, fffffe0014cdfaa8, fffffe0014cdf8c8, 18) at > ifq_dequeue+0x34 > http://www.openbsd.org/ddb.html describes the minimum info required in bug > reports. Insufficient info makes it difficult to find and fix bugs. > ddb> > > Once this was fixed, the machine crashes at an incoming packet on > the vxlan(4) interface. > > fatal kernel trap: > > trap entry = 0x4 (unaligned access fault) > a0 = 0xfffffc0001c63072 > a1 = 0x28 > a2 = 0x6 > pc = 0xfffffc00007b6ab8 > ra = 0xfffffc00007b68fc > curproc = 0xfffffc003fd5a960 > pid = 82287, comm = softnet > > panic: trap > Stopped at Debugger+0x8: lda sp,10(sp) > TID PID UID PRFLAGS PFLAGS CPU COMMAND > *82287 82287 0 0x14000 0x210 0 softnet > Debugger(1, fffffd01fc0003f8, fffffd01fc0003fd, 8, 3, fffffd0100000008) at > Debugger+0x8 > panic(?, 28, 6, 4, fffffe0014d83c20, fffffc0000000008) at panic+0xcc > trap(?, ?, ?, ?, ?, fffffc0000000008) at trap+0x138 > XentUna(?, ?, ?, ?, ?, fffffc0000000008) at XentUna+0x20 > ip6_input(fffffc003ff85f00, d3f2152afb6f8db3, fffffc0000906360, 0, 0, > fffffc0037296e00) at ip6_input+0x208 > ip6intr(fffffc003ff85f00, d3f2152afb6f8db3, fffffc0000906360, 0, 0, > fffffc0037296e00) at ip6intr+0x24 > http://www.openbsd.org/ddb.html describes the minimum info required in bug > reports. Insufficient info makes it difficult to find and fix bugs. > ddb> > > >How-To-Repeat: > For the first kernel trap: > # ifconfig vxlan0 create > # ifconfig vxlan0 inet6 2001:db8::1/32 > > Then, ping that address from the remote to cause another kernel > trap: > # ping6 2001:db8::1 > > >Fix: > I haven't fully understood how mbuf's work but by adding a m_pullup(9) after > M_PREPEND() seems to atleast make the first panic go away. > > How many bytes for m_pullup? In vxlan_output, sizeof (*vi) work but should > we do more? > > In vxlan_lookup, m_pullup by sizeof (*eh) was the only thing i could think > of trying. > > I remember that back in 2002 (kernel/3037 by mickey@) we had similar > unaligned access issues with rl(4). How times go by...
This was fixed around three weeks ago in -current. Try a snapshot.
