[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1535560111.23560.61.camel@arista.com>
Date: Wed, 29 Aug 2018 17:28:31 +0100
From: Dmitry Safonov <dima@...sta.com>
To: Jiri Slaby <jslaby@...e.cz>, linux-kernel@...r.kernel.org
Cc: Daniel Axtens <dja@...ens.net>,
Dmitry Safonov <0x7f454c46@...il.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Tan Xiaojun <tanxiaojun@...wei.com>,
Peter Hurley <peter@...leysoftware.com>,
Pasi Kärkkäinen <pasik@....fi>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Michael Neuling <mikey@...ling.org>,
Mikulas Patocka <mpatocka@...hat.com>
Subject: Re: [PATCH 3/4] tty: Lock tty pair in tty_init_dev()
On Wed, 2018-08-29 at 16:46 +0200, Jiri Slaby wrote:
> On 08/29/2018, 04:23 AM, Dmitry Safonov wrote:
> > It's safe to not lock both here - done to silence attempt lockdep
> > assert in
> > tty_ldisc_open(), which will be added with following patch.
>
> SOrry, could you elaborate here? I don't follow...
Sure, 4/4 patch adds lockdep_assert_held() into tty_ldisc_open().
Currently ldisc in tty->link isn't locked, which according to code
shouldn't be an issue, as far as I can see.
So, this patch silences lockdep warining by holding the semaphore,
which is slowpath anyway and doesn't case any new contention.
(actually, not holding the semaphore for slave might be an issue if one
opens slave before it's fully initialized, but I'm not sure if it's
possible).
--
Thanks,
Dmitry
Powered by blists - more mailing lists