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

[sc.dying%gmail.com@localhost]

The following reply was made to PR kern/54495; it has been noted by GNATS.

From: sc.dying%gmail.com@localhost
To: matthew green <mrg%eterna.com.au@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/54495: stopping axe(4) may locks up if NET_MPSAFE is enabled
Date: Thu, 29 Aug 2019 08:14:09 +0000

 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.