Skip site navigation (1)Skip section navigation (2)
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>