Felix Fietkau <[email protected]> writes: > On 2016-09-12 12:07, Johannes Berg wrote: >> On Mon, 2016-09-12 at 12:05 +0200, Felix Fietkau wrote: >>> On 2016-09-12 12:03, Johannes Berg wrote: >>> > >>> > >>> > > >>> > > Hm, I guess I didn't think of that. I guess this potential issue >>> > > will >>> > > go away once we get Toke's tx handler reorder patch fixed, >>> > > rebased >>> > > and integrated. >>> > > >>> > >>> > I don't really see how that helps? >>> It replaces the changes that I made. >>> >> >> But this is a more general problem, no? > Will look into it some more soon. > > - Felix
Well, ath9k calls ieee80211_tx_dequeue while holding the (driver) TXQ lock. Which means that a packet going through the old TX path can block waiting for the driver to finish pulling packets from the mac80211 queue. So that could definitely lead to reordering of sequence numbers. And the obvious fix of taking a lock in mac80211 could then lead to deadlock. Fun times! :) Hmm, is there a reason why those packets *have* to go through the old TX path? My reordering patchset introduces a queue that takes priority over the FQ (for fragments created after dequeue). Would sticking the PS response frame on there and having the driver pull it work? -Toke
