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]
Date:   Tue, 12 Dec 2017 09:59:45 +0100
From:   Toke Høiland-Jørgensen <>
To:     Johannes Berg <>,
        Stephen Rothwell <>,
        Kalle Valo <>,
        Wireless <>
Cc:     Linux-Next Mailing List <>,
        Linux Kernel Mailing List <>,
        Felix Fietkau <>,
        Lorenzo Bianconi <>,
        David Miller <>,
        Networking <>
Subject: Re: linux-next: build failure after merge of the mac80211-next tree

Johannes Berg <> writes:

> Hi Stephen,
> Thanks!
> Felix made me aware of this yesterday evening and said he's going to
> work out the required changes to mt76.
> Kalle and I will make sure to submit the trees to Dave one by one so he
> doesn't have to deal with it :)
> Unfortunately, this might take a few days to resolve.
>> -void mt76_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
>> +void mt76_wake_tx_queue(struct ieee80211_hw *hw)
>>  {
>> +	struct ieee80211_txq *txq;
>>  	struct mt76_dev *dev = hw->priv;
>> -	struct mt76_txq *mtxq = (struct mt76_txq *) txq->drv_priv;
>> -	struct mt76_queue *hwq = mtxq->hwq;
>> +	struct mt76_txq *mtxq;
>> +	struct mt76_queue *hwq;
>> +	txq = ieee80211_next_txq(hw);
>> +	mtxq = (struct mt76_txq *) txq->drv_priv;
>> +	hwq = mtxq->hwq;
> Looks pretty much right to me - perhaps for safety there should be a
> NULL check on txq, but OTOH when you get here it should be non-NULL.

Note that while this will fix compilation it probably won't work right.
next_txq() is not guaranteed to return the same txq as was previously
passed in the wake_tx_queue() argument, so if this is the only place the
driver calls next_txq(), things are likely going to break.

Rather, the driver should call next_txq() whenever it schedules queues
instead of doing its own internal scheduling.

> Sorry for the inconvenience, I hadn't realized mt76 went in now.

Yeah, hadn't expected these streams to cross either. If Felix is looking
into this that is great; let me know if you need me to do anything else
on the mac80211 side. :)


Powered by blists - more mailing lists