Date: Wed, 12 Jul 2017 19:20:28 +0100
From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Okash Khawaja <okash.khawaja@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jslaby@suse.com>,
        Samuel Thibault <samuel.thibault@ens-lyon.org>,
        linux-kernel@vger.kernel.org, William Hubbs <w.d.hubbs@gmail.com>,
        Chris Brannon <chris@the-brannons.com>, Kirk Reiser <kirk@reisers.ca>,
        speakup@linux-speakup.org, devel@driverdev.osuosl.org
Subject: Re: [patch 0/3] Re: tty contention resulting from
 tty_open_by_device export
Message-ID: <20170712192028.70bc0d54@alans-desktop>
In-Reply-To: <20170710123307.GA777@sanghar>
References: <20170708083803.GA23080@kroah.com>
        <20170709114153.157783481@gmail.com>
        <20170710125233.2006733e@alans-desktop>
        <20170710123307.GA777@sanghar>
Organization: Intel Corporation
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1318
Lines: 28


> When opening from kernel, we don't use file pointer. The count mismatch
> is between tty->count and #fd's. So opening from kernel leads to #fd's
> being less than tty->count. I thought this difference is relevant to
> user-space opening of tty, and not to kernel opening of tty. Can you
> suggest how to address this mismatch?

Your kernel reference is the same as having a file open reference so I
think this actually needs addressing in the maths. In other words count
the number of kernel references and also add that into the test for
check_tty_count (kernel references + #fds == count).

I'd really like to keep this right because that check has a long history
of catching really nasty race conditions in the tty code. The
open/close/hangup code is really fragile so worth the debugability.

> Ah may be I didn't notice the active bit. Is it one of the #defines in
> tty.h? Can usage count and active bit be used to differentiate between
> whether the tty was opened by kernel or user?

It only tells you whether the port is currently active for some purpose,
not which. If you still want to implement exclusivity between kernel and
user then it needs another flag, but I think that flag should be in
port->flags as it is a property of the physical interface.

(Take a look at tty_port_open for example)

Alan