[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170710162201.GB417@sanghar>
Date: Mon, 10 Jul 2017 17:22:01 +0100
From: Okash Khawaja <okash.khawaja@...il.com>
To: Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>,
Samuel Thibault <samuel.thibault@...-lyon.org>,
linux-kernel@...r.kernel.org, William Hubbs <w.d.hubbs@...il.com>,
Chris Brannon <chris@...-brannons.com>,
Kirk Reiser <kirk@...sers.ca>, speakup@...ux-speakup.org,
devel@...verdev.osuosl.org
Subject: Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device
export
On Mon, Jul 10, 2017 at 01:33:07PM +0100, Okash Khawaja wrote:
> > If the tty counts are being misreported then it would be better to fix
> > the code to actually manage the counts properly. The core tty code is
> > telling you that the tty is not in a valid state. While this is of
> > itself a good API to have, the underlying reference miscounting ought
> > IMHO to be fixed as well.
> 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?
Idea is tty_kopen only ever returns a newly initialised tty - returned
by tty_init_dev. Since the access is exclusive, tty->count shouldn't
matter. When the caller is done with it, it calls tty_release_struct
which frees up the tty itself.
But yes, all the while a tty is kopened, its tty->count and #fds will be
unequal.
Thanks,
Okash
Powered by blists - more mailing lists