On 2021/4/3 20:23, Jiri Kosina wrote: > 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.
Hi, Jiri Do you have a reproducer that can be shared here? With reproducer, I can debug and test it myself too. Thanks. > > [1] > https://lore.kernel.org/linux-can/1616641991-14847-1-git-send-email-linyunsh...@huawei.com/T/#u >
