svn commit: r343213 - in head/sys: net80211 sys

[Andriy Voskoboinyk]

Sun, 20 Jan 2019 16:02:08 +0200 було написано Bjoern A. Zeeb  
<bz at 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