Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752305AbdGILoa (ORCPT ); Sun, 9 Jul 2017 07:44:30 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:33320 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752258AbdGILo2 (ORCPT ); Sun, 9 Jul 2017 07:44:28 -0400 Message-Id: <20170709114153.157783481@gmail.com> User-Agent: quilt/0.65 Date: Sun, 09 Jul 2017 12:41:53 +0100 From: Okash Khawaja To: Greg Kroah-Hartman , Jiri Slaby , Samuel Thibault , Alan Cox , linux-kernel@vger.kernel.org Cc: William Hubbs , Chris Brannon , Kirk Reiser , speakup@linux-speakup.org, devel@driverdev.osuosl.org Subject: [patch 0/3] Re: tty contention resulting from tty_open_by_device export In-Reply-To: <20170708083803.GA23080@kroah.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 868 Lines: 20 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 Thanks, Okash