Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@redhat.com>
To:     Johannes Berg <johannes@sipsolutions.net>,
        linux-wireless@vger.kernel.org
Cc:     Jiri Kosina <jikos@kernel.org>, Aaron Hill <aa1ronham@gmail.com>,
        Lukas Redlinger <rel+kernel@agilox.net>,
        Oleksii Shevchuk <alxchk@gmail.com>
Subject: Re: [PATCH] mac80211: keep BHs disabled while calling drv_tx_wake_queue()
In-Reply-To: <bb98e67fd47effce9eada17bdf24a9d0b7102f31.camel@sipsolutions.net>
References: <1569924485-I3e8838c5ecad878e59d4a94eb069a90f6641461a@changeid> <87blv0visz.fsf@toke.dk> <bb98e67fd47effce9eada17bdf24a9d0b7102f31.camel@sipsolutions.net>
Date:   Tue, 01 Oct 2019 13:12:33 +0200
Message-ID: <87wodou3by.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Johannes Berg <johannes@sipsolutions.net> writes:

> On Tue, 2019-10-01 at 12:53 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote=
:
>>=20
>> > -=09=09=09spin_unlock_bh(&fq->lock);
>> > +=09=09=09spin_unlock(&fq->lock);
>> >  =09=09=09drv_wake_tx_queue(local, txqi);
>> > -=09=09=09spin_lock_bh(&fq->lock);
>> > +=09=09=09spin_lock(&fq->lock);
>>=20
>> Okay, so this will mean that the drv_wake_tx_queue() entry point will be
>> called with bhs disabled.
>
> Right.
>
>>  But there are lots of uses of
>> spin_{,un}lock_bh() in tx.c:
>
> [snip]
>
>> so won't that mean that the driver still gets bhs re-enabled after (for
>> instance) the first call to ieee80211_tx_dequeue()?
>
> No, local_bh_disable()/local_bh_enable() is re-entrant and nests fine.

Ah, right, gotcha. Hmm, in that case, would it be more clear to just add
an outer local_bh_disable()/local_bh_enable() to
___ieee80211_wake_txqs(). With this patch we're relying on the
mismatched use of _bh/non-_bh variants of the locking to ensure the bhs
stay off. Isn't that prone to breaking in the future?

Oh, and also, with just this patch, the additional drv_wake_tx_queue()
call for the vif TXQ at the bottom of __ieee80211_wake_txqs() will still
happen without bhs disabled, won't it?

-Toke