Re: WARNING in get_pi_state

[Dmitry Vyukov]

On Tue, Oct 31, 2017 at 12:16 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> So that provided repro.c thing doesn't work _at_all_.
>
> Its stuck on trying to create a tunnel for some daft reason.. I don't
> have that.
>
> I'll try and hack up the repro.c file to see if I can make it 'work',
> but it would be nice if reproducers could actually be ran without too
> much crap.


I understand your sentiment, but it's definitely not _at all_. The
system compiled this exact code, run it and triggered the bug on it.
Do you have suggestions on how to make this code more portable? How
does this setup would look on your system?

We do try hard to get rid of unnecessary stuff in reproducers. I think
what happened in this case is the following. This is a hard to
reproduce race. The bot was able to reproduce the crash on initial
program that uses tun, then tried to get rid of tun code and
re-reproduce it, but it did not reproduce this time, so it concluded
that tun code is somehow necessary here. That's unfortunate
consequence of testing complex concurrent code. May become somewhat
better once we have KTSAN, the race detector.