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]
Message-ID: <CA+55aFzNQe6WCHKBrs_xNY0MxzF4C9jpfLFjSh8GBFTEzGnxxg@mail.gmail.com>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ