From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932444AbdJZOcM (ORCPT ); Thu, 26 Oct 2017 10:32:12 -0400 Received: from www.llwyncelyn.cymru ([82.70.14.225]:43014 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932234AbdJZOcL (ORCPT ); Thu, 26 Oct 2017 10:32:11 -0400 Date: Thu, 26 Oct 2017 15:31:55 +0100 From: Alan Cox To: taoyuhong Cc: "gregkh@linuxfoundation.org" , "jslaby@suse.com" , Zhaoshenglong , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] tty: fix flush_to_ldisc() oops before tty_open is done Message-ID: <20171026153155.70c92343@alans-desktop> In-Reply-To: <5D766B1447A5304684CEC38F253A9297415D8B6F@DGGEMA503-MBX.china.huawei.com> References: <1508897735-30968-1-git-send-email-taoyuhong@huawei.com> <20171025202529.299d9c72@alans-desktop> <5D766B1447A5304684CEC38F253A9297415D8B6F@DGGEMA503-MBX.china.huawei.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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