linux-kernel - Re: [GIT, RFC] Killing the Big Kernel Lock

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: <20100324221016.0b444a23@lxorguk.ukuu.org.uk>
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/