linux-kernel - Re: [PATCH] tty: add lockdep annotations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 2 Jun 2012 15:25:29 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Alan Cox <alan@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jens Axboe <jaxboe@...ionio.com>
Subject: Re: [PATCH] tty: add lockdep annotations

On Sat, Jun 2, 2012 at 1:19 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>
> Yep. Been that way 8)
>
> tty_driver_remove_tty is called from tty_shutdown is called from the
> final tty_kref_put can be called from IRQ context.

Hmm. Ok. Looking at it, the ".shutdown" and ".remove" functions are
all very limited, so I suspect we could just make the rule be that the
install/lookup functions are serialized against each other by the
pty_mutex (true today), and then we just add a small spinlock for the
actual driver array insert/lookup.

So my patch could probably be munged to do something like that.

But since I want to close the merge window and release -rc1 today, it
does feel too late to start mucking with fundamental locking things.
So reverting is likely the right thing to do.

Can somebody double-check the attached revert commit? Did I miss some
commit that depended on the tty locking changes?

Eric, does this make things work for you again? When/if we get the
locking sorted out for the tty install/lookup/remove, we can revert
this revert and do the locking fixes on top of that.

Alan, please double-check my revert. I've done an allmodconfig build
with it, and I've looked at the patch and grepped that I didn't miss
any 'tty_[un]lock()' cases, but that's the limit of my
sanity-checking. I did check that this revert means that the main tty
files are now back in the same exact state they were before that
"tty_lock: Localise the lock" commit. I left the per-ldisc waitqueue
change in there, though, that one seemed independent.

                 Linus

Download attachment "tty-locking-revert.patch" of type "application/octet-stream" (27927 bytes)