Date: Wed, 25 Jan 2012 13:47:08 -0800 From: Adrian Chadd <adrian@freebsd.org> To: PseudoCylon <moonlightakkiy@yahoo.ca> Cc: freebsd-wireless@freebsd.org Subject: Re: net80211 race conditions seen in -HEAD Message-ID: <CAJ-VmomReMTTDQ3KYjbRTb4%2BLY%2BKVtkba_T0fwM49oHakW_XSg@mail.gmail.com> In-Reply-To: <CAFZ_MY%2BifiXc3iPfDEuWNHyr7JvhuG55uzp3BTmCO2Ek2G1LOg@mail.gmail.com> References: <CAFZ_MY%2BifiXc3iPfDEuWNHyr7JvhuG55uzp3BTmCO2Ek2G1LOg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25 January 2012 06:43, PseudoCylon <moonlightakkiy@yahoo.ca> wrote: > Here is my brain dump. > > While ago usb wifi drivers had the slimier issue (race in 80211 > stack). It's worth checking this rev. > http://svnweb.freebsd.org/base?view=revision&revision=212127 > > AK > Hi, right, but that isn't at all completely _atomic_. It's quite possible that the underlying node gets ripped out by thread B whilst the assignment is happening in thread A. Once you have that reference you're fine, but I can't see where the guarantee is that vap->iv_bss is actually going to stay referenced for the lifecycle of the call _to_ ieee80211_ref_node() (rather than the atomic increment itself.) The fundamental trouble there is that the assignment can and does occur whilst the refcount i Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomReMTTDQ3KYjbRTb4%2BLY%2BKVtkba_T0fwM49oHakW_XSg>