Re: HEAD/i386 r320212: three reproducible panics [see also bugzilla 220404 about a type of problem introduced in head -r329722 ]

[Just for the 3rd backtrace example. . .]

Oleg V. Nauman oleg at theweb.org.ua wrote on
Fri Jun 23 16:58:07 UTC 2017 :

. . .
> __curthread () at ./machine/pcpu.h:225
> 225      __asm("movl %%fs:%1,%0" : "=r" (td)
> (kgdb) #0  __curthread () at ./machine/pcpu.h:225
> #1  doadump (textdump=-968633856) at ../../../kern/kern_shutdown.c:318
> #2  0xc06e88c4 in kern_reboot (howto=<optimized out>)
>     at ../../../kern/kern_shutdown.c:386
> #3  0xc06e8c5b in vpanic (fmt=<optimized out>,
>     ap=0xefd5c73c "\340\334\235\300\310\370\266\306\001")
>     at ../../../kern/kern_shutdown.c:779
> #4  0xc06e8b1b in panic (fmt=0xc092e18e "%s")
>     at ../../../kern/kern_shutdown.c:710
> #5  0xc08eed21 in trap_fatal (frame=0xefd5c878, eva=<optimized out>)
>     at ../../../i386/i386/trap.c:978
> #6  0xc08eea38 in trap (frame=<optimized out>)
>     at ../../../i386/i386/trap.c:704
> #7  <signal handler called>
> #8  0xc6bcda1b in ?? ()
> #9  0xc0770281 in unp_connect2 (so=<optimized out>, so2=<optimized out>,
>     req=<optimized out>) at ../../../kern/uipc_usrreq.c:1497
> #10 0xc076ff17 in unp_connectat (fd=<optimized out>, so=<optimized out>,
>     nam=<optimized out>, td=<optimized out>)
>     at ../../../kern/uipc_usrreq.c:1446
> #11 0xc076d510 in unp_connect (so=0xc71c9400, nam=0xc662d500,
>     td=<optimized out>) at ../../../kern/uipc_usrreq.c:1310
> #12 uipc_connect (so=0xc71c9400, nam=0xc662d500, td=<optimized out>)
>     at ../../../kern/uipc_usrreq.c:587
> #13 0xc076a042 in kern_connectat (td=<optimized out>, dirfd=-100,
>     fd=<optimized out>, sa=0xc662d500) at ../../../kern/uipc_syscalls.c:505
> #14 0xc0769f49 in sys_connect (td=0xc6bcda18, uap=0xc6b6f988)
>     at ../../../kern/uipc_syscalls.c:470
> #15 0xc08ef679 in syscallenter (td=<optimized out>)
>     at ../../../i386/i386/../../kern/subr_syscall.c:132
> #16 syscall (frame=<optimized out>) at ../../../i386/i386/trap.c:1103
> #17 <signal handler called>
> #18 0x283a4747 in ?? ()
> Backtrace stopped: Cannot access memory at address 0xbfbfe794

There are problems with a union having fields
that interfere with each other. The details of
the layout and interference likely vary from
TARGET_ARCH to TARGET_ARCH. This is from
new material added in head -r319722 and
involves /head/sys/sys/socketvar.h and
the new union in struct socket.

See bugzilla 220404 and its analysis of a
repeatable crash on 32-bit powerpc for
head -r320482 (I'd made a large jump from
well before -r319722):

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220404

It also involves unp_connect2, unp_connect,
kern_connectat, sys_connect and is likely
involved. But different aliasing in the
union across architectures likely lead to
varying details for the behavior that results
from the bad handling of union use.

===
Mark Millard
markmi at dsl-only.net