From owner-freebsd-wireless@FreeBSD.ORG Sun Jul 29 02:25:46 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 BDF46106564A for ; Sun, 29 Jul 2012 02:25:46 +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 90F128FC0A for ; Sun, 29 Jul 2012 02:25:46 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so7959197pbb.13 for ; Sat, 28 Jul 2012 19:25:46 -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=gplvH3IiS5DDBFYOaBDxN5Qk3oV3j7Ia2dW9xc333m8=; b=YgWoLXts/bMXHn5ZP/urjV4xhsyXJfnN5yZRi9ftQrzdVvI2aClcjQ/fdPe6VcWr4z RgK0kUiNTOy24EEUVUSIZvIno5zCtO/Ycl60HHRKpgB1r9CgcGRtP4jX7Jp5rThYbhqR lIcoNZO8WHmYRo+0oa1ShuhS/pciBf94WXNonoqnx6CA8HxoduiSkSvKjr/Sk0qDpXJ0 Jr87gC2whUDJ/BTVgLnZ3zl4aNYqbkLD1tT6bQciyyR7iuu3FNKLmYiV8VkbcuTfTP9G 9wZOdaTwJoY1+YZxaC/MP2FjH3VS82u7lQ3f/vY4pEbuEgW6FnGWSZG776zCOEd6USpx 82iw== MIME-Version: 1.0 Received: by 10.66.88.39 with SMTP id bd7mr15337012pab.50.1343528746351; Sat, 28 Jul 2012 19:25:46 -0700 (PDT) Received: by 10.68.66.136 with HTTP; Sat, 28 Jul 2012 19:25:46 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 Jul 2012 19:25:46 -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: Sun, 29 Jul 2012 02:25:46 -0000 Hi everyone, I'd really appreciate some help with this LOR. Specifically, at least explicitly mapping out the different entry points into these two locks that can/do cause issues, so we can see whether the LOR can be worked around by ensuring the problematic locking doesn't occur in parallel. I don't have the time to do all of the net80211 locking fixes that are required _and_ port new Atheros 802.11n support _and_ implement hostap power save / filtered frames support _and_ fix up the aggregation session hangs that people see. I really, really could do with some help here. I'll provide free, cool wifi hardware to anyone who tackles and fixes any of the above issues. :-) Thanks, Adrian On 27 July 2012 12:33, Adrian Chadd wrote: > .. hm, so. This is quite annoying, really. > > ieee80211_iterate_nodes() is called from hostap_newstate() to do a > bunch of things, including: > > * calling sta_diassoc() on each STA; > * handling CSA for each STA (for DFS channel change) via sta_csa(); > * dropping stations when doing a CSA (via sta_drop()); > > Now, at this point the _newstate() routine has the comlock > (IEEE80211_LOCK()) held. > > So, any function that is passed to ieee80211_iterate_nodes() that also > tries to grab the comlock is going to silently fail. > > It may _be_ that the only sensible thing to do here is to force the > comlock is held before calling ieee80211_iterate_nodes(), and then > update all the functions that it calls to require the comlock be held. > > So, that'd currently be (in net80211, ignoring what are in drivers atm): > > * sta_leave() > * load_ucastkey() > * sta_disassoc() > * sta_csa() > * sta_drop() > * get_sta_space() > * get_sta_info() > * domlme() > * mesh_vdetach_peers() > * mesh_checkid() > * get_adhoc_rssi() > * get_hostap_rssi() > * get_mesh_rssi() > > .. and that's kind of scary, because a lot of those will call into the > driver and do things like transmit frames; and we absolutely can't > hold the comlock when doing that or all kinds of bad LORs will occur. > > Fixing this is going to take a little more time/patience. I'm open to > other ideas/suggestions on this. > > > > Adrian