[Bug 220404] head -r319722 or -r320224 related changes break powerpc production-style kernel operation: bad function pointer
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Sat Jul 1 01:48:33 UTC 2017
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220404
Bug ID: 220404
Summary: head -r319722 or -r320224 related changes break
powerpc production-style kernel operation: bad
function pointer
Product: Base System
Version: CURRENT
Hardware: powerpc
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: markmi at dsl-only.net
I am unable to complete a boot of a
old PowerMac G5 so-called "Quad Core"
under the 32-bit powerpc FreeBSD
version head -r320482 . (It was a
large jump to that from my prior
version.)
It looks like the 2 anonymous structs
in the union in the new "struct socket"
are being abused such that the ->sol_upcall
from the 2nd struct is being access when it
has a value that was apparently assigned
via ->so_rcv->sb_sel in the first
anonymous struct.
[Manually entered from camera pictures
of the screen but with notes added.]
fatal kernel trap
exception = 0x700 (program) (for "illegal instruction")
srr0 = 0x70bf878 (note: this varies, for example: 0x5e37230)
(note: r0 always matches srr0)
(note: ctr always matches srr0)
srr1 = 0x89032 (stays the same)
lr = 0x5b7b94 (note: solisten_wakeup+0x4c) (stays the same)
curthread = 0x5ab8ae0 (varies)
pid = 920 (varies), comm = mountd (stays the same)
Tracing command mountd pid 920 tid 100119 (varies) td 0x5ab8ae0 (varies)(CPU 1)
(stack addr
range varies)
0xd250a500: at soisconnected+0x21c (at stays the same)
0xd250a540: at unp_connect2+0xf0 (at stays the same)
0xd250a560: at unp_connectat+0x658 (at stays the same)
0xd250a770: at unp_connect+0x2c (at stays the same)
0xd250a790: at uipc_connect+0xc0 (at stays the same)
0xd250a7d0: at soconnectat+0xa0 (at stays the same)
0xd250a800: at soconnect+0x2c (at stays the same)
0xd250a820: at kern_connect+0134 (at stays the same)
0xd250a870: at sys_connect+0x64 (at stays the same)
0xd250a8b0: at trap+0x638 (at stays the same)
0xd250aa50: at powerpc_interrupt+0x1a0 (at stays the same)
0xd250aa80: at user SC trap (at stays the same)
by 0x419db168 (stays the same)
srr1=0xf032 (stays the same)
r1 =0xffffd5e0 (stays the same)
cr =0x24440840 (stays the same)
xer =0x20000000 (stays the same)
ctr =0x419db160 (stays the same)
005b7b84 <solisten_wakeup+0x3c> lwz r4,236(r3)
005b7b88 <solisten_wakeup+0x40> li r5,1
005b7b8c <solisten_wakeup+0x44> mtctr r0
005b7b90 <solisten_wakeup+0x48> bctrl
lr:
005b7b94 <solisten_wakeup+0x4c> b 005b7bb4 <solisten_wakeup+0x6c>
Note: r3 reported as: 0x70bf860
void
solisten_wakeup(struct socket *sol)
{
if (sol->sol_upcall != NULL)
(void )sol->sol_upcall(sol, sol->sol_upcallarg, M_NOWAIT);
else {
selwakeuppri(&sol->so_rdsel, PSOCK);
KNOTE_LOCKED(&sol->so_rdsel.si_note, 0);
}
SOLISTEN_UNLOCK(sol);
wakeup_one(&sol->sol_comp);
}
[Note: I've had to do some work to get a kgdb
working this much on powerpc. This is not
from a minidump.]
(kgdb) print/x &((struct socket*)0x70bf860)->sol_upcall
$3 = 0x70bf948
(kgdb) print/x ((struct socket*)0x70bf860)->sol_upcall
$2 = 0x70bf878
(That is the address of the illegal instruction
reported.)
(kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel
$7 = 0x70bf878
(kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel.si_tdlist
$8 = 0x70bf878
(kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel.si_tdlist.tqh_first
$9 = 0x70bf878
But comparing to the first anonymous struct in
the union in the new "struct socket":
(kgdb) print/x &((struct socket*)0x70bf860)->sol_upcall
$15 = 0x70bf948
(kgdb) print/x &((struct socket*)0x70bf860)->so_rcv->sb_sel
$22 = 0x70bf948
->so_rcv is a struct sockbuf and ->so_rcv->sb_sel
is a struct slinfo* .
So ->so_rcv->sb_sel pointing back to ->so_rdsel
might well make sense for that struct in the union.
But it appears to be the source of the 32-bit powerpc
crash during an attempted use of ->sol_upcall as well.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list