linux-kernel - Re: WARNING in get_pi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+YWxcTrqc1q42GHSMwakRzjWCiz4Y0f9-VfEuojDpgNsw@mail.gmail.com>
Date:   Tue, 31 Oct 2017 12:29:50 +0300
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     syzbot 
        <bot+2af19c9e1ffe4d4ee1d16c56ae7580feaee75765@...kaller.appspotmail.com>,
        dvhart@...radead.org, LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        syzkaller-bugs@...glegroups.com,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: WARNING in get_pi_state

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