linux-kernel - Re: [PATCH] tty: fix flush_to_ldisc() oops before 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20171026153155.70c92343@alans-desktop>
Date:   Thu, 26 Oct 2017 15:31:55 +0100
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     taoyuhong <taoyuhong@...wei.com>
Cc:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "jslaby@...e.com" <jslaby@...e.com>,
        Zhaoshenglong <zhaoshenglong@...wei.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tty: fix flush_to_ldisc() oops before tty_open is done

> I can reproduce this problem on CentOS now. It seems better to leave this problem to drivers, not the user process.
> Do you think we should examine serial drivers of ARM, like pl011?

Can you reproduce it on real hardware - I ask because the driver has been
around for years without reports and it would be good to know it's not a
virtual platform problem you are chasing.

> ---------------------------------------------------------------------------------------
> Does it means this serial driver do not support activate/deactive? Is that out of date?
> Because tty driver is complex, I am studying the concept and source code, and need time to find a good solution.

AMBA uses the uart layer. So uart does a lot of the work. 

Yes the driver is complex and the core hangup/receive paths are tricky to
understand. The open path however is fairly simple so the fact you see a
failure there makes me suspicious and I tink that is the first one to
trace because the tty_open paths do not set port->tty until the tty is
initialized properly.

The hangup path is complex and has a history of bugs and races so is a
bit less surprising.

The important detail here is that both the queueing of data and the
hangup are done by schedule_work() and as far as I can see (the code
has changed somewhat since I last dug into that bit) rely on that to avoid
the two executing at the same time.

Alan