From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752296AbdGIPEU (ORCPT ); Sun, 9 Jul 2017 11:04:20 -0400 Received: from mail-qt0-f176.google.com ([209.85.216.176]:35939 "EHLO mail-qt0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750997AbdGIPET (ORCPT ); Sun, 9 Jul 2017 11:04:19 -0400 MIME-Version: 1.0 In-Reply-To: <20170709114426.618570903@gmail.com> References: <20170708083803.GA23080@kroah.com> <20170709114153.157783481@gmail.com> <20170709114426.618570903@gmail.com> From: Andy Shevchenko Date: Sun, 9 Jul 2017 18:04:17 +0300 Message-ID: Subject: Re: [patch 1/3] tty: resolve tty contention between kernel and user space To: Okash Khawaja Cc: Greg Kroah-Hartman , Jiri Slaby , Samuel Thibault , Alan Cox , "linux-kernel@vger.kernel.org" , William Hubbs , Chris Brannon , Kirk Reiser , speakup@linux-speakup.org, devel@driverdev.osuosl.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 9, 2017 at 2:41 PM, Okash Khawaja wrote: > +struct tty_struct *tty_kopen(dev_t device) > +{ > + struct tty_struct *tty; > + struct tty_driver *driver = NULL; > + int index = -1; > + > + mutex_lock(&tty_mutex); > + driver = tty_lookup_driver(device, NULL, &index); > + if (IS_ERR(driver)) { > + mutex_unlock(&tty_mutex); > + return ERR_CAST(driver); Hmm... perhaps tty = ERR_CAST(driver); goto out_unlock; See below for further details. > + } > + > + /* check whether we're reopening an existing tty */ > + tty = tty_driver_lookup_tty(driver, NULL, index); > + if (IS_ERR(tty)) > + goto out; > + > + if (tty) { > + /* drop kref from tty_driver_lookup_tty() */ > + tty_kref_put(tty); > + tty = ERR_PTR(-EBUSY); > + } else { /* tty_init_dev returns tty with the tty_lock held */ > + tty = tty_init_dev(driver, index); > + set_bit(TTY_KOPENED, &tty->flags); > + } > +out: out_unlock: ? > + mutex_unlock(&tty_mutex); > + tty_driver_kref_put(driver); I'm not sure I understand locking model here: Above 1. take mutex 2. take reference Here: 1. give mutex back 2. give reference back I think we usually see symmetrical calls, i.e. 1. give reference back 2. give mutex back So, what did I miss? > + return tty; > +} -- With Best Regards, Andy Shevchenko