[Bug 220404] head -r319722 or -r320224 related changes break powerpc production-style kernel operation: bad function pointer

[bugzilla-noreply at freebsd.org]

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.