From owner-freebsd-wireless@FreeBSD.ORG Fri Jul 27 19:21:39 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 72DA7106566B for ; Fri, 27 Jul 2012 19:21:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 46CB28FC0A for ; Fri, 27 Jul 2012 19:21:39 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so5863451pbb.13 for ; Fri, 27 Jul 2012 12:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GYcdVfNChWY2aBt3mMOmm3OVnP3SyqlqwNxTd8XGHJM=; b=H3ibI61NEFb8ahe/WoSAltUgmMbcUSgJdD4hfq/nvV5rL4vab+K5uRmz57Uvf8wHg3 GHsn9l+YGi/UFIchAa+v5im/T0pds6572C6xUSVt65lNeviOuJWZH4/Br3OKjEHiwE37 W8dLr2AZ/MxgWuL5j5eQnn6p43iFx6GEW6G+BAg4DC8+6Kf97zgKW6cDHsfTwP2z/Z98 llaWFnRH/NjAGf0ms0A12gE79YXwZVq8tYEeTDjKEkqWk9XOHVwq84cHh7zmf4czeiXc KP2hUcSlpKnLEShKKutGFcUAKf/iPNsAp/W4eGHzKgrT555FQAqXTyfIyYk4LuIJC9W0 4CCA== MIME-Version: 1.0 Received: by 10.68.228.2 with SMTP id se2mr16303447pbc.109.1343416899049; Fri, 27 Jul 2012 12:21:39 -0700 (PDT) Received: by 10.68.66.136 with HTTP; Fri, 27 Jul 2012 12:21:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Jul 2012 12:21:39 -0700 Message-ID: From: Adrian Chadd To: Kim Culhan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: ath lor 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: Fri, 27 Jul 2012 19:21:39 -0000 Ok, hm. I wonder if the "correct" thing to do here is to ensure the comlock is NOT held when iterating through nodes. I don't know if net80211 ever had the lock hierarchy defined/designed in any detail. So it's either: * ieee80211_iterate_nodes() shouldn't be called with the comlock/nodelock/node iterate lock held; * ieee80211_iterate_nodes() must always be called with the comlock held. I bet it's the former. The latter is too scary. :-) I'll add a lock witness check on a local device and get a backtrace. If you'd like to immediately crash your device, you could do the same. If you're feeling very brave and immediately crash-y, try: Index: sys/net80211/ieee80211_node.c =================================================================== --- sys/net80211/ieee80211_node.c (revision 238389) +++ sys/net80211/ieee80211_node.c (working copy) @@ -2163,6 +2163,12 @@ struct ieee80211_node *ni; u_int gen; + /* + * To avoid LORs, ic must not be held here as the + * called function may acquire ic. + */ + IEEE80211_UNLOCK_ASSERT(nt->nt_ic); + IEEE80211_NODE_ITERATE_LOCK(nt); gen = ++nt->nt_scangen; restart: Index: sys/net80211/ieee80211_freebsd.h =================================================================== --- sys/net80211/ieee80211_freebsd.h (revision 238389) +++ sys/net80211/ieee80211_freebsd.h (working copy) @@ -53,6 +53,8 @@ #define IEEE80211_UNLOCK(_ic) mtx_unlock(IEEE80211_LOCK_OBJ(_ic)) #define IEEE80211_LOCK_ASSERT(_ic) \ mtx_assert(IEEE80211_LOCK_OBJ(_ic), MA_OWNED) +#define IEEE80211_UNLOCK_ASSERT(_ic) \ + mtx_assert(IEEE80211_LOCK_OBJ(_ic), MA_NOTOWNED) /* * Node locking definitions. Adrian