From: Arnd Bergmann <arnd@arndb.de>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
John Kacur <jkacur@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Al Viro <viro@zeniv.linux.org.uk>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 6/6] procfs: Kill the bkl in ioctl
Date: Wed, 31 Mar 2010 23:04:30 +0200 [thread overview]
Message-ID: <201003312304.30917.arnd@arndb.de> (raw)
In-Reply-To: <201003312221.23953.arnd@arndb.de>
On Wednesday 31 March 2010 22:21:23 Arnd Bergmann wrote:
> Another crazy idea I had was to simply turn the BKL into a regular mutex
> as soon as we can show that all remaining users are of the non-recursive
> kind and don't rely on the autorelease-on-sleep. Doing that would be
> much easier without the pushdown into .unlocked_ioctl than it would be
> with it.
I just looked at all the users of lock_kernel remaining with my patch
series. For 90% of them, it is completely obvious that they don't rely
on nested locking, and they very much look like they don't need the
autorelease either, because the BKL was simply pushed down into the
open, ioctl and llseek functions.
There are a few file systems (udf, ncpfs, autofs, coda, ...) and some
network protocols (appletalk, ipx, irnet and x25) for which it is not
obviously, though still quite likely, the case.
So we could actually remove the BKL recursion code soon, or even turn
all of it into a regular mutex, at least as an experimental option.
The recursive users that I've removed in my series are the block, tty,
input and sound subsystems, as well as the init code.
Arnd
next prev parent reply other threads:[~2010-03-31 21:05 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-30 6:20 [PATCH 0/6] Kill the bkl in procfs Frederic Weisbecker
2010-03-30 6:20 ` [PATCH 1/6] procfs: Kill BKL in llseek on proc base Frederic Weisbecker
2010-03-30 6:40 ` Alexey Dobriyan
2010-03-30 6:50 ` Frederic Weisbecker
2010-03-30 6:20 ` [PATCH 2/6] procfs: Use generic_file_llseek in /proc/kcore Frederic Weisbecker
2010-03-30 10:28 ` Arnd Bergmann
2010-03-30 6:20 ` [PATCH 3/6] procfs: Use generic_file_llseek in /proc/kmsg Frederic Weisbecker
2010-03-30 10:38 ` Arnd Bergmann
2010-03-30 6:20 ` [PATCH 4/6] procfs: Use generic_file_llseek in /proc/vmcore Frederic Weisbecker
2010-03-30 10:38 ` Arnd Bergmann
2010-03-30 6:20 ` [PATCH 5/6] procfs: Push down the bkl from ioctl Frederic Weisbecker
2010-03-30 6:31 ` Alexey Dobriyan
2010-03-30 7:02 ` Frederic Weisbecker
2010-04-09 14:45 ` [PATCH v2] " Frederic Weisbecker
2010-04-10 13:25 ` [PATCH v3] " Frederic Weisbecker
2010-05-17 1:23 ` [PATCH v4] " Frederic Weisbecker
2010-03-30 10:37 ` [PATCH 5/6] " Arnd Bergmann
2010-03-30 18:27 ` Frederic Weisbecker
2010-03-30 18:54 ` Arnd Bergmann
2010-03-30 19:21 ` Frederic Weisbecker
2010-03-30 6:20 ` [PATCH 6/6] procfs: Kill the bkl in ioctl Frederic Weisbecker
2010-03-30 6:38 ` Alexey Dobriyan
2010-03-30 7:07 ` Frederic Weisbecker
2010-03-30 10:33 ` Arnd Bergmann
2010-03-31 17:22 ` Frederic Weisbecker
2010-03-31 20:21 ` Arnd Bergmann
2010-03-31 21:04 ` Arnd Bergmann [this message]
2010-03-31 21:55 ` Alan Cox
2010-04-01 9:07 ` Arnd Bergmann
2010-03-31 21:56 ` Frederic Weisbecker
2010-04-01 11:37 ` Arnd Bergmann
2010-04-01 10:22 ` John Kacur
2010-03-31 21:41 ` Frederic Weisbecker
2010-04-01 12:42 ` Arnd Bergmann
2010-04-03 17:53 ` Stefan Richter
2010-04-10 16:09 ` Frederic Weisbecker
2010-04-12 15:05 ` Arnd Bergmann
2010-04-10 16:14 ` Frederic Weisbecker
2010-04-10 16:24 ` Frederic Weisbecker
2010-04-01 11:39 ` Stefan Richter
2010-04-01 12:45 ` Arnd Bergmann
2010-04-10 15:28 ` Frederic Weisbecker
2010-04-11 13:03 ` Christoph Hellwig
2010-04-12 17:34 ` Arnd Bergmann
2010-04-12 21:53 ` Frederic Weisbecker
2010-04-13 9:26 ` Arnd Bergmann
2010-04-13 20:10 ` Frederic Weisbecker
2010-04-13 18:03 ` Christoph Hellwig
2010-04-10 13:27 ` [PATCH 0/6] Kill the bkl in procfs Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201003312304.30917.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=jkacur@redhat.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.