linux-kernel - Re: [PATCH wireless 2/5] wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87bka7wkfm.fsf@protonmail.com>
Date: Sat, 30 Dec 2023 19:37:56 +0000
From: Rahul Rameshbabu <sergeantsagara@...tonmail.com>
To: Michael Büsch <m@...s.ch>
Cc: Julian Calaby <julian.calaby@...il.com>, Kalle Valo <kvalo@...nel.org>, linux-wireless@...r.kernel.org, b43-dev@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH wireless 2/5] wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled

On Sat, 30 Dec, 2023 18:41:13 +0100 Michael Büsch <m@...s.ch> wrote:
> [[PGP Signed Part:Undecided]]
> On Sat, 30 Dec 2023 17:15:18 +0000
> Rahul Rameshbabu <sergeantsagara@...tonmail.com> wrote:
>
>> On Sat, 30 Dec, 2023 14:40:36 +0100 Michael Büsch <m@...s.ch> wrote:
>> > [[PGP Signed Part:Undecided]]
>> > On Sat, 30 Dec 2023 18:48:45 +1100
>> > Julian Calaby <julian.calaby@...il.com> wrote:  
>> >> > --- a/drivers/net/wireless/broadcom/b43/dma.c
>> >> > +++ b/drivers/net/wireless/broadcom/b43/dma.c
>> >> > @@ -1399,7 +1399,10 @@ int b43_dma_tx(struct b43_wldev *dev, struct sk_buff *skb)
>> >> >             should_inject_overflow(ring)) {
>> >> >                 /* This TX ring is full. */
>> >> >                 unsigned int skb_mapping = skb_get_queue_mapping(skb);
>> >> > -               ieee80211_stop_queue(dev->wl->hw, skb_mapping);
>> >> > +               if (dev->qos_enabled)
>> >> > +                       ieee80211_stop_queue(dev->wl->hw, skb_mapping);
>> >> > +               else
>> >> > +                       ieee80211_stop_queue(dev->wl->hw, 0);    
>> >> 
>> >> Would this be a little cleaner if we only look up the queue mapping if
>> >> QOS is enabled? I.e.  
>> >
>> > No. It would break the other uses of skb_mapping.
>> >
>> > But I am wondering why skb_mapping is non-zero in the first place.
>> > I think the actual bug might be somewhere else.  
>> 
>> Right, skb_mapping is used to map to the correct software structures DMA
>> mapped to the device. The reason the mapping for the best effort queue
>> (the default/defacto when QoS is disabled) is not zero is due to the way
>> initialization of the queues/rings occurs in the driver. The best effort
>> queue is mapped as the third queue, which leads to this issue when QoS
>> is disabled. Would it make more sense to change the mappings in
>> initialization such that the best effort queue is by default mapped to
>> zero, so we would not need such conditionals?
>
> Maybe it is a good idea to find the patch that broke non-QoS.
> That possibly helps to understand the situation.
>
> Non-QoS used to work just fine.

I did some git analysis, and I actually believe that this issue has been
present since the commit e6f5b934fba8 ("b43: Add QOS support"). Before
then, non-QOS would not trigger this issue. There is a cosmetic change
after this commit, b27faf8ebf25 ("b43: Rename the DMA ring pointers"),
but this change does not introduce the issue (but makes it more
obvious). I think the reason nobody has ever reported this is that even
when the warnings are triggered, everything appears to work fine. I
think therefore the two options are the following.

1. Remap the BE queue to 0 instead of the BK queue.
2. Use this kind of conditional to handle the mapping when QoS is
   disabled.

--
Thanks,

Rahul Rameshbabu