Re: uhso(4) locking issues

[Iain Hibbert <plunky%ogmig.net@localhost>]

On Sat, 19 Jul 2014, Kamil Rytarowski wrote:

> plunky @ NetBSD the original commiter (and author?)

yes I wrote this originally

> Unfortunatelly, I've got issues with the driver with LOCKDEBUG turned on
> (expensive locking checks/support), and these issues result in kernel
> panics.

Is this with LOCKDEBUG and no other changes, or with LOCKDEBUG and the
addition of the MPSAFE flag?  I must admit, I have not tried LOCKDEBUG for
quite some time, since I have no way on this laptop to retrieve the dmesg
buffer after a reboot.

> Grzegorz found at least two bugs and told me that the driver has to be
> discussed with authors and most likely parly rewritten.

> I issue: spin lock held when taking mutex
> And uhso_tty_write() at src/sys/dev/usb/uhso.c takes mutex.

Hmm.. except it does not?

int
uhso_tty_write(dev_t dev, struct uio *uio, int flag)
{
        struct uhso_softc *sc = device_lookup_private(&uhso_cd, UHSOUNIT(dev));
        struct uhso_port *hp = sc->sc_port[UHSOPORT(dev)];
        struct tty *tp = hp->hp_tp;
        int error;

        if (!device_is_active(sc->sc_dev))
                return EIO;

        DPRINTF(5, "sc=%p, hp=%p, tp=%p\n", sc, hp, tp);

        sc->sc_refcnt++;

        error = tp->t_linesw->l_write(tp, uio, flag);

        if (--sc->sc_refcnt < 0)
                usb_detach_wakeupold(sc->sc_dev);

        return error;
}

> So the general question is, has it ever been tested for
> lock-correctness? What would be the correct way to resolve it (in a
> fix-it-yourself approach)? Is possible to do so in uhso(4) without
> touching subsystems?

Nope, because the uhso driver does not do any locking directly..  there is
USB locking and TTY locking which must interact and I am not sure what
work has been done to make drivers MPSAFE in general.

iain