All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Peter Zijlstra <peterz@infradead.org>
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 12:29:50 +0300	[thread overview]
Message-ID: <CACT4Y+YWxcTrqc1q42GHSMwakRzjWCiz4Y0f9-VfEuojDpgNsw@mail.gmail.com> (raw)
In-Reply-To: <20171031091603.plulggamkcfh7k3u@hirez.programming.kicks-ass.net>

On Tue, Oct 31, 2017 at 12:16 PM, Peter Zijlstra <peterz@infradead.org> 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.

  reply	other threads:[~2017-10-31  9:30 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 [this message]
2017-10-31 10:08     ` Peter Zijlstra
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=CACT4Y+YWxcTrqc1q42GHSMwakRzjWCiz4Y0f9-VfEuojDpgNsw@mail.gmail.com \
    --to=dvyukov@google.com \
    --cc=bot+2af19c9e1ffe4d4ee1d16c56ae7580feaee75765@syzkaller.appspotmail.com \
    --cc=dvhart@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --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.