Sun, 20 Jan 2019 16:02:08 +0200 було написано Bjoern A. Zeeb
<b...@freebsd.org>:
On 20 Jan 2019, at 13:39, Andriy Voskoboinyk wrote:
Author: avos
Date: Sun Jan 20 13:39:18 2019
New Revision: 343213
URL: https://svnweb.freebsd.org/changeset/base/343213
Log:
net80211: resolve ioctl <-> detach race for ieee80211com structure
Since r287197 ieee80211com is a part of drivers softc; as a result,
after detach all pointers to it (iv_ic, ni_ic) are invalid. Most
possible users (tasks, interrupt handlers) are blocked / removed
when device is stopped; however, ioctl handlers were not tracked
and may crash if ieee80211com structure is accessed.
Since ieee80211com pointer access from ieee80211vap structure is not
protected by lock (constant after interface creation) and used in
many other places just use reference counting for ioctl handlers;
on detach set 'detached' flag and wait until reference counter goes
to 0.
So how do any cloned interfaces do this (wifi or non-wifi)? Is this a
more general problem or are some wifi drivers just not exactly careful
with the order they take things down?
That's for wifi only; ifp (and vap as subpart) is alive until
reference counter for ifp is not 0; however, 'com' gets invalid
as soon as device detach procedure is finished - and net80211
uses it in various places inside ieee80211_ioctl().
On another note, why would refcount(9) not be sufficient? I didn’t
really like the MC() macros and the hand crafted state machine for a
refcount when scrolling through.
Just to keep 'detached' flag and reference counter inside one variable
(they both need to be atomically accessible).
/bz
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
