Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752179AbdGIL5v (ORCPT ); Sun, 9 Jul 2017 07:57:51 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:41634 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752050AbdGIL5u (ORCPT ); Sun, 9 Jul 2017 07:57:50 -0400 Date: Sun, 9 Jul 2017 13:57:45 +0200 From: Greg Kroah-Hartman To: Okash Khawaja Cc: Jiri Slaby , Samuel Thibault , Alan Cox , linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org, Kirk Reiser , Chris Brannon , speakup@linux-speakup.org Subject: Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export Message-ID: <20170709115745.GC14769@kroah.com> References: <20170708083803.GA23080@kroah.com> <20170709114153.157783481@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170709114153.157783481@gmail.com> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1264 Lines: 27 On Sun, Jul 09, 2017 at 12:41:53PM +0100, Okash Khawaja wrote: > On Sat, Jul 08, 2017 at 10:38:03AM +0200, Greg Kroah-Hartman wrote: > > Overall, the idea looks sane to me. Keeping userspace from opening a > > tty that the kernel has opened internally makes sense, hopefully > > userspace doesn't get too confused when that happens. I don't think we > > normally return -EBUSY from an open call, have you seen what happens > > with apps when you do this (like minicom?) > > > I tested this wil minincom, picocom and commands like "echo foo > > /dev/ttyS0". They all correctly report "Device or resource busy". > > I have addressed all the comments you made. I have also split the patch > into three. Following is summary of each. > > Patch 1: introduces the tty_kopen function and checks for TTY_KOPENED > Patch 2: updates speakup code to use tty_kopen instead of > tty_open_by_driver > Patch 3: reverses the export of tty_open_by_driver Looks great, only one tiny comment about the return value from me, and really, it's not a big deal at all, you can send a patch 4/3 to change that up if you want. No one really runs without the tty layer enabled :) If there are no other objections, I'll queue this up after 4.13-rc1 is out, nice job. greg k-h