linux-kernel - Re: INFO: task hung in __sb_start

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: <e7c307e5-97be-8fe7-1380-42201e043de3@i-love.sakura.ne.jp>
Date:   Tue, 19 Jun 2018 22:00:47 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will.deacon@....com>,
        syzbot <syzbot+7b2866454055e43c21e5@...kaller.appspotmail.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: INFO: task hung in __sb_start_write

On 2018/06/19 20:47, Dmitry Vyukov wrote:
>> If no, we would want a git tree for testing under syzbot.
> 
> Thinking of this, we could setup a sandbox instance that won't report
> anything over email at all, but crashes will be available on the web.
> We could point this instance to a custom git tree, where additional
> patches can be applied as necessary.  The main question is: who and
> how will manage this tree? The tree needs to be rebased periodically,
> patches applied, old patches taken out.
> 

The simplest approach (if Linus can tolerate) would be to merge any
debug printk() patches to linux.git with single kernel config option
(e.g. CONFIG_DEBUG_AID_FOR_SYZBOT=y) for turning them on/off.
Assuming that we will eventually be able to move to saving and analyzing
vmcore files, some bit of debug printk() code would be tolerable for now?

Other possible approach (if Andrew can tolerate) would be to use
linux-next.git and carry debug printk() patches via mmotm tree.