On Wed, May 27, 2020 at 2:12 AM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > Hi again Klemens, > > On Tue, May 26, 2020 at 5:42 PM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > > > On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > > With regards to your crash, though, that's a bit more puzzling, and > > > I'd be interested to learn more details. Because these structs are > > > already naturally aligned, the __packed attribute, even with the odd > > > nesting Matt had prior, should have produced all entirely aligned > > > accesses. That makes me think your kaboom was coming from someplace > > > else. One possibility is that you were running the git tree on the two > > > days that I was playing with uint128_t, only to find out that some of > > > openbsd's patches to clang miscalculate stack sizes when they're in > > > use, so that work was shelved for another day and the commits removed; > > > perhaps you were just unlucky? Or you hit some other bug that's > > > lurking. Either way, output from ddb's `bt` would at least be useful. > > > > Do you know off hand if we're able to assume any type of alignment > > with mbuf->m_data? mtod just casts without any address fixup, which > > means if mbuf->m_data isn't aligned by some other mechanism, we're in > > trouble. But I would assume there _is_ some alignment imposed, since > > the rest of the stack appears to parse tcp headers and such directly > > without byte-by-byte copies being made. > > After a day of TCG-run compilation, I've got a working sparc64 setup > and can confirm the issue. Working on a fix.
The latest git master should work well now: solar# arch -s sparc64 solar# wg-quick up demo [#] ifconfig wg0 create [#] wg setconf wg0 /dev/fd/63 [#] ifconfig wg0 inet 192.168.4.155/24 alias [#] ifconfig wg0 mtu 1420 [#] ifconfig wg0 up [#] cp /etc/resolv.conf /etc/resolv.conf.wg-quick-backup.demo [#] printf nameserver %s\n 8.8.8.8 8.8.4.4 1.1.1.1 1.0.0.1 [#] route -q -n add -inet 0.0.0.0/1 -iface 192.168.4.155 [#] route -q -n add -inet 128.0.0.0/1 -iface 192.168.4.155 [#] route -q -n delete -inet 163.172.161.0 [#] route -q -n add -inet 163.172.161.0 -gateway 10.0.2.2 [+] Backgrounding route monitor solar# curl zx2c4.com/ip 163.172.161.0 demo.wireguard.com One interesting quirk in doing this on qemu is that the 6.7 and -current kernel both crash: Loading FCode image... Loaded 6882 bytes entry point is 0x4000 Evaluating FCode... OpenBSD IEEE 1275 Bootblock 2.0 Unhandled Exception 0x0000000000000030 PC = 0x00000000ffd0f3ac NPC = 0x00000000ffd0f3b0 Stopping execution Luckily it works fine on 6.6, so that's where I debugged this issue. But this might be a bug worth looking into. Otto's recent bootblk patch is a possible culprit, so I've CC'd him. Jason
