Re: kern/58466: Kernel panic in ucompoll

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Jul 24 21:48:55 slave /netbsd: [ 2260291.0658539] uvm_fault(0xffff92260e431b38, 0x0, 1) -> e

The 0x0 here means something is trying to use the null page.

> Jul 24 21:48:55 slave /netbsd: [ 2260291.0658539] trap type 6 code 0 rip 0xffffffff804957ff cs 0x8 rflags 0x10246 cr2 0xe8 ilevel 0 rsp 0xffffcb8450369bf0

The cr2 here is the actual address, 0xe8.

> Jul 24 21:48:55 slave /netbsd: [ 2260291.0678538] ucompoll() at netbsd:ucompoll+0x2a

This is the faulting instruction, and:

(gdb) x/i ucompoll+0x2a
   0xffffffff804be468 <ucompoll+42>:    mov    0xe8(%rax),%edi
(gdb) print &((struct ucom_softc *)0)->sc_tty
$2 = (struct tty **) 0xe8
(gdb) list *(ucompoll+0x2a)
0xffffffff804be468 is in ucompoll (/home/riastradh/netbsd/current/src/sys/dev/usb/ucom.c:849).
844     int
845     ucompoll(dev_t dev, int events, struct lwp *l)
846     {
847             const int unit = UCOMUNIT(dev);
848             struct ucom_softc * const sc = device_lookup_private(&ucom_cd, unit);
849             struct tty *tp = sc->sc_tty;
850     
851             UCOMHIST_FUNC(); UCOMHIST_CALLED();
852     
853             return (*tp->t_linesw->l_poll)(tp, events, l);

So sc is null, and it crashes trying to compute sc->sc_tty.

But how is sc null?  It shouldn't be possible to enter ucompoll
without a device private for the unit number -- either:

(a) there has never been such a unit, in which case there should be no
    paths to ucompoll with this number; or

(b) that unit is being detached concurrently, in which case spec_poll
    should either

     i. acquire a reference that blocks detach from finishing until
        ucompoll done (by holding up spec_io_drain which holds up
        spec_close which holds up vdevgone), or

    ii. (possibly block and then) fail with POLLERR, via failure in
        spec_io_enter -> vdead_check, without entering ucompoll; or

(c) that unit has been detached, in which case the vnode has been
    revoked with vdevgone in ucomdetach and should no longer be
    accessible as such and ucompoll should again not be entered.

Obviously I'm missing a path where control can sneak into ucompoll
with a detached unit, though!