Re: kern/54495: stopping axe(4) may locks up if NET_MPSAFE is enabled

[sc.dying%gmail.com@localhost]

On Wed, Aug 28, 2019 at 10:45 PM matthew green <mrg%eterna.com.au@localhost> wrote:
>
> actually, i see how usbnet_tick triggers this.  some of
> the driver did this, and i copied it into all, but i see
> how it is espcially bad for axe(4) -- it has many many
> more usbd_delay_us() calls compared to most of the other
> usbnet converted drivers.
>
> i can see a few ideas for fixes.
>
> - remove any access to adaptive locks in softint context,
>   which comes down to don't take the lock in usbnet_tick().
>
> - arrange to have the un_lock passed to kpause so it is
>   dropped and re-taken during kpause.
>
> - push *all* the work in usbnet_tick() into the
>   usbnet_tick_task() (hm, this may also be #1.)

My idea was
- call callout_halt instead of callout_stop to wait for its completion
  before calling unp_stop.

It does not solve problem.

> i think the first idea is best and simplest.  i suspect
> that it needs to be written like;
>
>         struct usbnet_private * const unp = un->un_pri;
>
>         if (unp != NULL && !unp->unp_stopping && !unp->unp_dying) {
>                 /* Perform periodic stuff in process context */
>                 usb_add_task(un->un_udev, &unp->unp_ticktask, USB_TASKQ_DRIVER);
>         }
>
> can you test?  my axe(4) is broken.

It works. I repeated 10 times ifconfig up and down but it does not lock up.

>
> (i've got a few more fixes to check unp for NULL in a
> tree i'm testing, thanks to a report from maxv about
> upl(4) crash during detach, which is the only fixed
> part so far, though the rest of them are more safety
> than actually fixing bugs.)
>
> thanks.
>
>
> .mrg.

Thanks.