linux-kernel - Re: [PATCHv5 0/7] tty: Hold write ldisc sem in tty

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: <1537388512.21380.44.camel@arista.com>
Date:   Wed, 19 Sep 2018 21:21:52 +0100
From:   Dmitry Safonov <dima@...sta.com>
To:     Mikulas Patocka <mpatocka@...hat.com>
Cc:     linux-kernel@...r.kernel.org,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Daniel Axtens <dja@...ens.net>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Mark Rutland <mark.rutland@....com>,
        Michael Neuling <mikey@...ling.org>,
        Nathan March <nathan@...net>,
        Pasi Kärkkäinen <pasik@....fi>,
        Peter Hurley <peter@...leysoftware.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Rong, Chen" <rong.a.chen@...el.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Tan Xiaojun <tanxiaojun@...wei.com>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        stable@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>, Jiri Slaby <jslaby@...e.cz>,
        syzbot+3aa9784721dfb90e984d@...kaller.appspotmail.com
Subject: Re: [PATCHv5 0/7] tty: Hold write ldisc sem in tty_reopen()

On Wed, 2018-09-19 at 16:03 -0400, Mikulas Patocka wrote:
> 
> On Wed, 19 Sep 2018, Dmitry Safonov wrote:
> > Thanks much for the testing, Mikulas.
> > Could you try to bisect which of the patches causes it?
> > The most important are 1,2,3 - probably, one of them caused it..
> > I'll stare a bit into the code.
> 
> The patch 3 causes it.
> 
> The hangs during reboot take either 80 seconds, 3 minutes or 3:25.

Thanks much for that again.
Any chance you have sysrq enabled and could print: locks held in system
and kernel backtraces for applications?

I suppose, userspace hangs in n_tty_receive_buf_common(), which is
better of cause than null-ptr dereference, but I believe we can improve
it by stopping a reader earlier if there is any writer pending.

-- 
Thanks,
             Dmitry