Re: WARNING in get_pi_state

2017-11-07 Thread Dmitry Vyukov
On Tue, Oct 31, 2017 at 11:38 AM, Peter Zijlstra wrote: > On Tue, Oct 31, 2017 at 11:31:34AM +0100, Peter Zijlstra wrote: > >> And of course, now it went *splat*, lemme continue staring.. > > PEBKAC, turns out I was running the kernel without the patch in, and it > only took 3100 seconds to trigge

Re: WARNING in get_pi_state

2017-11-07 Thread Dmitry Vyukov
On Tue, Oct 31, 2017 at 11:08 AM, Peter Zijlstra wrote: > 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 t

Re: WARNING in get_pi_state

2017-11-01 Thread Peter Zijlstra
On Tue, Oct 31, 2017 at 11:38:12AM +0100, Peter Zijlstra wrote: > On Tue, Oct 31, 2017 at 11:31:34AM +0100, Peter Zijlstra wrote: > > > And of course, now it went *splat*, lemme continue staring.. > > PEBKAC, turns out I was running the kernel without the patch in, and it > only took 3100 seconds

Re: WARNING in get_pi_state

2017-10-31 Thread Peter Zijlstra
On Tue, Oct 31, 2017 at 11:31:34AM +0100, Peter Zijlstra wrote: > And of course, now it went *splat*, lemme continue staring.. PEBKAC, turns out I was running the kernel without the patch in, and it only took 3100 seconds to trigger the splat.. I am now actually running the kernel with the patch

Re: WARNING in get_pi_state

2017-10-31 Thread Peter Zijlstra
On Tue, Oct 31, 2017 at 01:23:13PM +0300, Dmitry Vyukov wrote: > But having said that, the tun code is not supposed to make the > reproducer non-working either. E.g. on our systems it just setups tun > successfully and then proceeds to the actual code that triggers the > problem. What's the failur

Re: WARNING in get_pi_state

2017-10-31 Thread Peter Zijlstra
On Tue, Oct 31, 2017 at 11:18:53AM +0100, Peter Zijlstra wrote: > On Tue, Oct 31, 2017 at 09:36:44AM +0100, Peter Zijlstra wrote: > > On Mon, Oct 30, 2017 at 12:44:00PM -0700, syzbot wrote: > > > WARNING: CPU: 1 PID: 24353 at kernel/futex.c:818 get_pi_state+0x15b/0x190 > > > kernel/futex.c:818 > >

Re: WARNING in get_pi_state

2017-10-31 Thread Dmitry Vyukov
On Tue, Oct 31, 2017 at 1:21 PM, Dmitry Vyukov wrote: > On Tue, Oct 31, 2017 at 1:08 PM, Peter Zijlstra wrote: >> 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 t

Re: WARNING in get_pi_state

2017-10-31 Thread Dmitry Vyukov
On Tue, Oct 31, 2017 at 1:08 PM, Peter Zijlstra wrote: > 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

Re: WARNING in get_pi_state

2017-10-31 Thread Peter Zijlstra
On Tue, Oct 31, 2017 at 09:36:44AM +0100, Peter Zijlstra wrote: > On Mon, Oct 30, 2017 at 12:44:00PM -0700, syzbot wrote: > > WARNING: CPU: 1 PID: 24353 at kernel/futex.c:818 get_pi_state+0x15b/0x190 > > kernel/futex.c:818 > > > exit_pi_state_list+0x556/0x7a0 kernel/futex.c:932 > > mm_release+0x

Re: WARNING in get_pi_state

2017-10-31 Thread Peter Zijlstra
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 lo

Re: WARNING in get_pi_state

2017-10-31 Thread Dmitry Vyukov
On Tue, Oct 31, 2017 at 12:16 PM, Peter Zijlstra 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

Re: WARNING in get_pi_state

2017-10-31 Thread Peter Zijlstra
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.

Re: WARNING in get_pi_state

2017-10-31 Thread Peter Zijlstra
On Mon, Oct 30, 2017 at 12:44:00PM -0700, syzbot wrote: > WARNING: CPU: 1 PID: 24353 at kernel/futex.c:818 get_pi_state+0x15b/0x190 > kernel/futex.c:818 > exit_pi_state_list+0x556/0x7a0 kernel/futex.c:932 > mm_release+0x46d/0x590 kernel/fork.c:1191 > exit_mm kernel/exit.c:499 [inline] > do_exi

Re: WARNING in get_pi_state

2017-10-30 Thread Dmitry Vyukov
On Mon, Oct 30, 2017 at 10:44 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 8fd0520d9cec0896d48d3921bc642a9ee81eae0c > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer is