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:	Wed, 24 Mar 2010 22:10:16 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org, Matthew Wilcox <matthew@....cx>,
	Thomas Gleixner <tglx@...utronix.de>, jblunck@...e.de,
	Alan Cox <alan@...ux.intel.com>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [GIT, RFC] Killing the Big Kernel Lock

> - The most invasive change is in the TTY layer, which has a new global
>   mutex (sorry!). I know that Alan has plans of his own to remove the BKL
>   from this subsystem, so my patches may not go anywhere, but they seem
>   to work fine for me.
>   I've called the new lock the 'Big TTY Mutex' (BTM), a name that probably
>   makes more sense if you happen to speak German.

Chuckle (I don't but I looked it up)

>   The basic idea here is to make recursive locking and the release-on-sleep
>   explicit, so every mutex_lock, wait_event, workqueue_flush and schedule
>   in the TTY layer now explicitly releases the BTM before blocking.

I'm not sure if that is actually the path of sanity (yours at least), nor
the right way to whack the other BKL users whose use is horrible but
essentially private.

It would be nice to get the other bits in first removing BKL from most of
the kernel and building kernels which are non BKL except for the tty
layer. That (after Ingo's box from hell has run it a bit) would
reasonably test the assertion that the tty layer has no BKL requirements
that are driven by external to tty layer code.

That to me would test the biggest question of all and be a reasonably
good base from which to then either apply the tty BTM patches or attack
the problem properly with the BKL localised to one subtree.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ