From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751338AbdFEPJ3 (ORCPT <rfc822;w@1wt.eu>);
        Mon, 5 Jun 2017 11:09:29 -0400
Received: from www.llwyncelyn.cymru ([82.70.14.225]:52388 "EHLO fuzix.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751194AbdFEPJ2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 5 Jun 2017 11:09:28 -0400
Date: Mon, 5 Jun 2017 16:09:12 +0100
From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Mike Galbraith <efault@gmx.de>
Cc: Vegard Nossum <vegard.nossum@oracle.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Dave Jones <davej@codemonkey.org.uk>,
        Linux Kernel <linux-kernel@vger.kernel.org>,
        Jiri Slaby <jslaby@suse.com>
Subject: Re: [bisected] Re: tty lockdep trace
Message-ID: <20170605160912.56c76d68@lxorguk.ukuu.org.uk>
In-Reply-To: <1496576071.6573.13.camel@gmx.de>
References: <20170531172117.nj5fwgqspibg7rs6@codemonkey.org.uk>
        <1496471632.11868.1.camel@gmx.de>
        <20170604083225.GA2959@kroah.com>
        <1496566972.16375.10.camel@gmx.de>
        <6b025884-8fbc-1ae2-3119-63e601453ad6@oracle.com>
        <1496576071.6573.13.camel@gmx.de>
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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, 04 Jun 2017 13:34:31 +0200
Mike Galbraith <efault@gmx.de> wrote:

> On Sun, 2017-06-04 at 12:00 +0200, Vegard Nossum wrote:
> > 
> > I don't know how you did it, but this passes my testing (reproducers for
> > both the original issue and the lockdep splat/hang).  
> 
> I suppose I can sign it off, see if that inspires anyone to come up
> with something better.
> 
> drivers/tty: Fix 925bb1ce47f4 circular locking dependency

This is still completely broken and has the same underlying flaw as the
original.

The tty->atomic_write_lock is solely meant to enforce the ordering of a
write() syscall. It can be held for an indefinite amount of time (it's
sometimes multiple seconds in normal flow). Your patch effectively breaks
full duplex support on the serial layer because the internal buffering is
designed to cope with tens of millisecond delays. If the receiver is
multithreaded as is normal then it's also going to wreck the throughput.

We can't defer receive processing indefintiely for transmit processing,
that isn't how RS232 works. If it needs a spinlock putting back to
protect those tty fields then so be it.

NAK

Alan