Date: Sat, 01 Jul 2017 01:48:33 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 220404] head -r319722 or -r320224 related changes break powerpc production-style kernel operation: bad function pointer Message-ID: <bug-220404-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220404 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@FreeBSD.org Reporter: markmi@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 =3D 0x700 (program) (for "illegal instruction") srr0 =3D 0x70bf878 (note: this varies, for example: 0x5e37230) (note: r0 always matches srr0) (note: ctr always matches srr0) srr1 =3D 0x89032 (stays the same) lr =3D 0x5b7b94 (note: solisten_wakeup+0x4c) (stays the same) curthread =3D 0x5ab8ae0 (varies) pid =3D 920 (varies), comm =3D mountd (stays the same) Tracing command mountd pid 920 tid 100119 (varies) td 0x5ab8ae0 (varies)(CP= U 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=3D0xf032 (stays the same) r1 =3D0xffffd5e0 (stays the same) cr =3D0x24440840 (stays the same) xer =3D0x20000000 (stays the same) ctr =3D0x419db160 (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 !=3D 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 =3D 0x70bf948 (kgdb) print/x ((struct socket*)0x70bf860)->sol_upcall $2 =3D 0x70bf878 (That is the address of the illegal instruction reported.) (kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel $7 =3D 0x70bf878 (kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel.si_tdlist $8 =3D 0x70bf878 (kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel.si_tdlist.tqh_first $9 =3D 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 =3D 0x70bf948 (kgdb) print/x &((struct socket*)0x70bf860)->so_rcv->sb_sel $22 =3D 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-220404-8>