Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Mar 2016 10:43:32 -0700
From:      John Baldwin <jhb@freebsd.org>
To:        Adrian Chadd <adrian.chadd@gmail.com>
Cc:        Gleb Smirnoff <glebius@freebsd.org>, Hans Petter Selasky <hselasky@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r296909 - head/sys/ofed/drivers/infiniband/ulp/ipoib
Message-ID:  <208354486.x7l0Vtjzkk@ralph.baldwin.cx>
In-Reply-To: <CAJ-Vmoke9LX=9DqjuchAvaG=v4UzE2izNP%2BrHVkc6KuztVnK4w@mail.gmail.com>
References:  <201603151547.u2FFlQKN078643@repo.freebsd.org> <5463538.GTDDlnsCR6@ralph.baldwin.cx> <CAJ-Vmoke9LX=9DqjuchAvaG=v4UzE2izNP%2BrHVkc6KuztVnK4w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, March 16, 2016 03:37:09 PM Adrian Chadd wrote:
> I've fought this problem in USB drivers. Ideally you'd also have the
> detach path /also/ take said lock and drain anyone currently doing
> anything active (tx, rx, ioctls, net80211 methods, etc) to completion
> before continuing.
> 
> A lot of drivers don't do this very well, or at all.

There isn't a lock to take in detach to hold over drains.  Instead, the
various detach APIs (like if_detach) need to drain internally.  Only the
ifnet layer can keep track of if an ifnet is currently "busy" (any methods
currently executing for example).  You can't do that in the driver.  This is
why bus_teardown_intr() does a drain for example (as well as
callout_drain()).  destroy_dev() also handles this more correctly as it
does a drain (and drivers can even provide a d_purge callback to wakeup any
waiters inside of cdevsw methods during the drain).  if_detach() doesn't do
any drain at all and is broken.  It has to be fixed in the ifnet layer.
Changes in drivers are just band-aids (the current band-aids in this commit
and in other NIC drivers previously only hide witness warnings, they do
nothing to solve the problem of some thread that is already inside of
an if_foo method still running when detach is called, particularly if an
if_foo method can sleep).

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?208354486.x7l0Vtjzkk>