On 2019-09-23 18:56, Toke Høiland-Jørgensen wrote:
Yibo Zhao <yiboz@xxxxxxxxxxxxxx> writes:
In a loop txqs dequeue scenario, if the first txq in the rbtree gets
removed from rbtree immediately in the ieee80211_return_txq(), the
loop will break soon in the ieee80211_next_txq() due to schedule_pos
not leading to the second txq in the rbtree. Thus, defering the
removal right before the end of this schedule round.
Didn't we agree that we could fix this by making __unschedule_txq()
aware of schedule_pos instead of this deferred removal mechanism?
Yes, V3 is actually used to update the commit log of [PATCH V3 3/4] so
that we can discuss in parallel with others, and [PATCH V3 4/4] for
discussion. Please ignore [PATCH V3 2/4]. we can keep our discussion in
V2 until we conclude the final one and then a new version will be sent
out along with [mac80211: Switch to a virtual time-based airtime
scheduler] which includes the reducing lock fix.
Sorry for the confusion, ;).
-Toke
--
Yibo
