On Fri, 2018-08-31 at 08:54 +0200, Jiri Slaby wrote: > On 08/29/2018, 06:28 PM, Dmitry Safonov wrote: > > 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. > > Eh, no... Adding a lock just to make lockdep happy is a no-go. The > locking in tty is already complex enough. > > > (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). > > If that turns out to be a problem, we can apply the patch. BUt unless > it > is proven to be so (be it code review or a reproducer), let's leave > the > locking as it is.
Ok, than for v2 I'll just remove lockdep_assert() from tty_ldisc_open(). -- Thanks, Dmitry