Re: 6.0-BETA2: taskqueue_drain for if_xl.c:2796

From: Scott Long (scottl_at_samsco.org)
Date: 08/12/05

  • Next message: Beecher Rintoul: "dhclient problems" 
    Date: Thu, 11 Aug 2005 17:07:06 -0600
To: John Baldwin <jhb@FreeBSD.org>

    John Baldwin wrote:

    > On Thursday 11 August 2005 05:41 pm, John Baldwin wrote:
    >
    >>On Thursday 11 August 2005 04:09 pm, Joerg Pulz wrote:
    >>
    >>>Hi,
    >>>
    >>>with a fresh installed 6.0-BETA2 i get this when xl(4) gets configured at
    >>>the system startup.
    >>>System is P3-800MHz SMP. dmesg is attached.
    >>
    >>I'm working on fixes for this. Ping me in a day or so for a patch.
    >
    >
    > Ok, I've got a patch. I added a taskqueue_stop() function to bring
    > taskqueue's a bit closer inline with the callout*() API and use
    > taskqueue_stop() in xl_stop() as it is ok to be called with locks held and
    > doesn't block. The xl task handler function now bails if IFF_DRV_RUNNING is
    > clear, and I added a taskqueue_drain() in detach to make sure we were
    > finished with the mutex and function before detach finishes. Unfortunately,
    > the patch is to HEAD, but you can probably get it to work on 6.x by changing
    > if_drv_flags to if_flags and IFF_DRV_RUNNING to IFF_RUNNING on 6.x.
    >
    > http://www.FreeBSD.org/~jhb/patches/xl_locking

    It looks like taskqueue_stop merely removes a pending task from the
    queue, it doesn't protect against there being a task already running
    and/or sleeping. I know that you're looking for the convenience of
    being able to cancel a taskqueue without having to worry about locks,
    but ignoring the possibility of an in-progress task is dangerous. It's
    incovenient, but it's the price of concurrency in the kernel. I've
    objected to callout_stop for the same reason. Never the less, if you're
    looking to have a similar API as callout_*, why not follow their model
    and have _taskqueue_stop_safe() ?

    Scott
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Beecher Rintoul: "dhclient problems"

    Relevant Pages

    • Re: usbd doesnt get DEVICE_DETACH? (plus patch for typo in usbd.c)
      ... I will check your patch. ... > usbd then launches a ppp instance for that port, ... > daemon for the Palm device. ... > device detach in the DRIVER_DETACH event (probably won't work if there's ...
      (freebsd-current)
    • Re: [PATCH] ugen detach race
      ... patch fixes a problem where read, write, and ioctl can be ... This doesn't fix the case where an application has a read/write ... pending and then detach is called. ... This seems to fix all the panics I'm seeing with the ugen device. ...
      (freebsd-current)
    • Re: [PATCH] ugen detach race
      ... patch fixes a problem where read, write, and ioctl can be ... This doesn't fix the case where an application has a read/write ... pending and then detach is called. ... This seems to fix all the panics I'm seeing with the ugen device. ...
      (freebsd-current)
    • Re: [PATCH] ugen detach race
      ... On Wednesday 05 April 2006 04:44, Anish Mistry wrote: ... This includes the patch from usb/81308 to ... pending and then detach is called. ... The patch should fix usb/93949 too. ...
      (freebsd-current)
    • Re: 6.0-BETA2: taskqueue_drain for if_xl.c:2796
      ... > I'm working on fixes for this. ... Ping me in a day or so for a patch. ... finished with the mutex and function before detach finishes. ...
      (freebsd-current)