From owner-freebsd-wireless@FreeBSD.ORG Wed Jan 25 21:47:09 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE4CC106566C for ; Wed, 25 Jan 2012 21:47:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 989A68FC19 for ; Wed, 25 Jan 2012 21:47:09 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so2750297vbb.13 for ; Wed, 25 Jan 2012 13:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ARYmlZuBViFFiVRAYZqK0SQTgo8trRO59FQvAqcAfWc=; b=Kk6mPNtFCnshcBpVWpwjiGCPWhkGlEo7M2gQHTvxuiMxLIhu1X5fdbru3TJ0HnOq+C bHIoK5ftUFPXr2lTBDWlhcAURBjJYkRQsUT6bDkJqNSJ7XeVLR0H40MDboV+Rwf/SdHD +6YV7XMVWLCcy+/OB3zBljQx5kbyZSsfi2F1M= MIME-Version: 1.0 Received: by 10.52.94.73 with SMTP id da9mr10211598vdb.6.1327528028869; Wed, 25 Jan 2012 13:47:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.71.241 with HTTP; Wed, 25 Jan 2012 13:47:08 -0800 (PST) In-Reply-To: References: Date: Wed, 25 Jan 2012 13:47:08 -0800 X-Google-Sender-Auth: VH7Gz4IM9R4qzqUhduPgQ3fCHTk Message-ID: From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-wireless@freebsd.org Subject: Re: net80211 race conditions seen in -HEAD X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:47:09 -0000 On 25 January 2012 06:43, PseudoCylon 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