Hi Paolo,
On 06/02/2020 14.21, Paolo Abeni wrote:
On Tue, 2020-02-04 at 17:25 +0100, Ahmad Fatoum wrote:
Hello Paolo,
On 1/20/20 5:06 PM, Ahmad Fatoum wrote:
Hello Paolo,
On 1/16/20 1:40 PM, Paolo Abeni wrote:
I'm sorry for this trial & error experience. I tried to reproduce the
issue on top of the vcan virtual device, but it looks like it requires
the timing imposed by a real device, and it's missing here (TL;DR: I
can't reproduce the issue locally).
No worries. I don't mind testing.
Code wise, the 2nd patch closed a possible race, but it dumbly re-
opened the one addressed by the first attempt - the 'empty' field must
be cleared prior to the trylock operation, or we may end-up with such
field set and the queue not empty.
So, could you please try the following code?
Unfortunately, I still see observe reodering.
Any news?
I'm unable to find any better solution than a revert. That will cost
some small performace regression, so I'm a bit reluctant to go ahead.
If there is agreement I can post the revert.
Is it possible that the current pfifo_fast handling has some additional
problems:
https://marc.info/?l=linux-netdev&m=158092393613669&w=2
Or is this unrelated?
Best,
Oliver
