From: Peter Zijlstra <peterz@infradead.org>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: syzbot
<bot+2af19c9e1ffe4d4ee1d16c56ae7580feaee75765@syzkaller.appspotmail.com>,
dvhart@infradead.org, LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
syzkaller-bugs@googlegroups.com,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: WARNING in get_pi_state
Date: Tue, 31 Oct 2017 11:08:52 +0100 [thread overview]
Message-ID: <20171031100852.pdifddw4lkc5fqfc@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CACT4Y+YWxcTrqc1q42GHSMwakRzjWCiz4Y0f9-VfEuojDpgNsw@mail.gmail.com>
On Tue, Oct 31, 2017 at 12:29:50PM +0300, Dmitry Vyukov wrote:
> 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?
So I don't see the point of that tun stuff; what was is supposed to do?
All it ever did after creation was flush_tun(), which reads until empty.
But given nobody would ever write into it, that's an 'expensive' NO-OP.
> 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.
I ripped out the tun bits and it reproduced in ~100 seconds. I've now
got it running for well over 30m on the fixed kernel while I'm trying to
come up with a comprehensible Changelog ;-)
next prev parent reply other threads:[~2017-10-31 10:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-30 19:44 WARNING in get_pi_state syzbot
2017-10-30 19:53 ` Dmitry Vyukov
2017-10-31 8:36 ` Peter Zijlstra
2017-10-31 10:18 ` Peter Zijlstra
2017-10-31 10:31 ` Peter Zijlstra
2017-10-31 10:38 ` Peter Zijlstra
2017-11-01 8:45 ` Peter Zijlstra
2017-11-07 16:16 ` Dmitry Vyukov
2017-10-31 12:06 ` [tip:core/urgent] futex: Fix more put_pi_state() vs. exit_pi_state_list() races tip-bot for Peter Zijlstra
2017-10-31 22:11 ` Thomas Gleixner
2017-11-01 8:05 ` Ingo Molnar
2017-11-01 8:09 ` tip-bot for Peter Zijlstra
2017-10-31 9:16 ` WARNING in get_pi_state Peter Zijlstra
2017-10-31 9:29 ` Dmitry Vyukov
2017-10-31 10:08 ` Peter Zijlstra [this message]
2017-10-31 10:21 ` Dmitry Vyukov
2017-10-31 10:23 ` Dmitry Vyukov
2017-10-31 10:36 ` Peter Zijlstra
2017-11-07 14:50 ` Dmitry Vyukov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171031100852.pdifddw4lkc5fqfc@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bot+2af19c9e1ffe4d4ee1d16c56ae7580feaee75765@syzkaller.appspotmail.com \
--cc=dvhart@infradead.org \
--cc=dvyukov@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.