On Sat, 3 Apr 2021, Hillf Danton wrote: > >>> Sure. Seems they crept in over time. I had some plans to write a > >>> lockless HTB implementation. But with fq+EDT with BPF it seems that > >>> it is no longer needed, we have a more generic/better solution. So > >>> I dropped it. Also most folks should really be using fq, fq_codel, > >>> etc. by default anyways. Using pfifo_fast alone is not ideal IMO. > >> > >> Half a year later, we still have the NOLOCK implementation > >> present, and pfifo_fast still does set the TCQ_F_NOLOCK flag on itself. > >> > >> And we've just been bitten by this very same race which appears to be > >> still unfixed, with single packet being stuck in pfifo_fast qdisc > >> basically indefinitely due to this very race that this whole thread began > >> with back in 2019. > >> > >> Unless there are > >> > >> (a) any nice ideas how to solve this in an elegant way without > >> (re-)introducing extra spinlock (Cong's fix) or > >> > >> (b) any objections to revert as per the argumentation above > >> > >> I'll be happy to send a revert of the whole NOLOCK implementation next > >> week. > >> > >Jiri > > > > Feel free to revert it as the scorch wont end without a deluge.
I am still planning to have Yunsheng Lin's (CCing) fix [1] tested in the coming days. If it works, then we can consider proceeding with it, otherwise I am all for reverting the whole NOLOCK stuff. [1] https://lore.kernel.org/linux-can/1616641991-14847-1-git-send-email-linyunsh...@huawei.com/T/#u -- Jiri Kosina SUSE Labs
