Return-path: Received: from s3.sipsolutions.net ([5.9.151.49]:54018 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932260AbdIFOaD (ORCPT ); Wed, 6 Sep 2017 10:30:03 -0400 Message-ID: <1504708200.23905.3.camel@sipsolutions.net> (sfid-20170906_163032_400195_9EA98853) Subject: Re: hung task in mac80211 From: Johannes Berg To: Stefano Brivio Cc: Matteo Croce , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 06 Sep 2017 16:30:00 +0200 In-Reply-To: <20170906162748.071b040e@elisabeth> References: <1504702728.13457.17.camel@sipsolutions.net> <20170906162748.071b040e@elisabeth> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, 2017-09-06 at 16:27 +0200, Stefano Brivio wrote: > > Sorry for the extended bothering :) but here, you're extending quite > a bit the scope of the lock also > when__ieee80211_start_rx_ba_session() is called by > ieee80211_process_addba_request(). I know, but it doesn't matter. > No idea what the hit can be, but we can't safely assume it's > nothing either. We don't really have to assume anything, we can read the code :-) Trust me, I probably wrote most of it. It's fine, just sanity checks. > What about simply introducing a 'ampdu_mlme_lock_held' argument > instead? Eww, no. johannes