From patchwork Wed Sep 5 10:22:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Bob Copeland X-Patchwork-Id: 10588739 X-Patchwork-Delegate: johannes@sipsolutions.net Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 68B4A13BB for ; Wed, 5 Sep 2018 10:23:22 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 509ED26BE9 for ; Wed, 5 Sep 2018 10:23:22 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4446129875; Wed, 5 Sep 2018 10:23:22 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B2E7426BE9 for ; Wed, 5 Sep 2018 10:23:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727629AbeIEOwx (ORCPT ); Wed, 5 Sep 2018 10:52:53 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:54012 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727603AbeIEOwx (ORCPT ); Wed, 5 Sep 2018 10:52:53 -0400 Received: by mail-it0-f65.google.com with SMTP id p79-v6so9153644itp.3 for ; Wed, 05 Sep 2018 03:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bobcopeland-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=bgmFMfWdE7QZFZqtTJ45qZq9CXpH+m0m4WCNRtXhrcQ=; b=q8cl4LS26/yojIXsKP29qEP37kLeuyG2sMt6b4THaHWkFAsWLf6GhGvHKA5mQUkr+a i6LunzjCmfBSwuN99GhUjcDIMUrXXvSONGU2aGGKumNA5/CofHPSzO9feHRlz2OFGJ0v sSauPYkxNLkkcZR0j0rBEc8NwvKrhu5aba7BzXPxjL0GB77L8Zl3TYl6HFuOXO7oGEOO G1fOq3F8CGihlAncx/F27lkkvm5s/WsBnJz0DoaqUYbzQVSs9grhejy+yl0kTbbss/fq QHt9Z0AMpolY00xwC8rur0WacfpQs6Gr4MYsq5aiNTuA+iekyqQR/rcoa/d4HVH/QXat 9M6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=bgmFMfWdE7QZFZqtTJ45qZq9CXpH+m0m4WCNRtXhrcQ=; b=T1idNdwa4ysBHfdEIR9rhbAb+kTMObVIOohj3J0ACVelQ9h4MHbnoK5zijiSpn0rla KApI/7gYrgfvJvJEmGN8A7aHOXoHq2PT05p92OQ4JHYfRJIxW6FSbZKsQVqlCQNodXDP GHh7rPAacZVgoTPdtpXGshYa1mp/GeGyDTbO1XpDOvlaDkg7wqJ7gHo9pw3qezb62IUr YoIkzKtYam6GUNT9pgoDIgJk+QhH73En/ViBP2a1zScq6SIjdNLcNBQ/SOHRZPbJGSNK pfLGEiSLf3OQcViBSUDb3Cb5tCIW4KRwwQhqWUtVKxhdvh6c6w3odYCvyV3Nl0yjd+Jr cV3Q== X-Gm-Message-State: APzg51B2ArXHPopKS4wpfT6QgJKvEfTan/mWlZrLDolxbleT1Quyj5hf nerDRw1C273Xyt1VJ97gma2J1Sj0mAA= X-Google-Smtp-Source: ANB0VdYGjDOiS3/8WBbF7K78ZjPkNp0MrPJ1TOtsfs3k+UFq4qKluXWwsURVGTAuWNPeL1dV9hROLg== X-Received: by 2002:a24:4254:: with SMTP id i81-v6mr10218975itb.95.1536142999330; Wed, 05 Sep 2018 03:23:19 -0700 (PDT) Received: from hash (CPE30b5c2fb365b-CM18593342f28f.cpe.net.cable.rogers.com. [99.232.51.173]) by smtp.gmail.com with ESMTPSA id b3-v6sm690057itj.32.2018.09.05.03.23.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Sep 2018 03:23:18 -0700 (PDT) Received: from bob by hash with local (Exim 4.89) (envelope-from ) id 1fxUxx-0004CV-Ma; Wed, 05 Sep 2018 06:23:17 -0400 From: Bob Copeland To: Johannes Berg Cc: linux-wireless@vger.kernel.org, Bob Copeland , Bob Copeland Subject: [PATCH] mac80211: fix pending queue hang due to TX_DROP Date: Wed, 5 Sep 2018 06:22:59 -0400 Message-Id: <20180905102259.16089-1-me@bobcopeland.com> X-Mailer: git-send-email 2.11.0 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP In our environment running lots of mesh nodes, we are seeing the pending queue hang periodically, with the debugfs queues file showing lines such as: 00: 0x00000000/348 i.e. there are a large number of frames but no stop reason set. One way this could happen is if queue processing from the pending tasklet exited early without processing all frames, and without having some future event (incoming frame, stop reason flag, ...) to reschedule it. Exactly this can occur today if ieee80211_tx() returns false due to packet drops or power-save buffering in the tx handlers. In the past, this function would return true in such cases, and the change to false doesn't seem to be intentional. Fix this case by reverting to the previous behavior. Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Bob Copeland Acked-by: Toke Høiland-Jørgensen --- net/mac80211/tx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index e88547842239..6b83dc397c3e 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -1907,7 +1907,7 @@ static bool ieee80211_tx(struct ieee80211_sub_if_data *sdata, sdata->vif.hw_queue[skb_get_queue_mapping(skb)]; if (invoke_tx_handlers_early(&tx)) - return false; + return true; if (ieee80211_queue_skb(local, sdata, tx.sta, tx.skb)) return true;