[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201006172140.46203.arnd@arndb.de>
Date: Thu, 17 Jun 2010 21:40:45 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Tony Luck <tony.luck@...el.com>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
Greg KH <gregkh@...e.de>,
Frederic Weisbecker <fweisbec@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
John Kacur <jkacur@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH v3 00/10] BKL conversion in tty layer
On Thursday 17 June 2010 21:13:52 Tony Luck wrote:
> These changes showed up in linux-next (tag: next-20100617) ... and I'm seeing
> a few WARN_ON messages on ia64 while booting:
>
> WARNING: at include/linux/tty.h:589 tty_open+0x160/0xc60()
> ...
> Stack trace for the first of these looks like:
> Call Trace:
> ...
> [<a0000001001c5270>] do_filp_open+0x2f0/0xb40
> [<a0000001001a5290>] do_sys_open+0x90/0x200
> [<a0000001001a54d0>] sys_open+0x50/0x80
> [<a000000100b907e0>] kernel_init+0x340/0x420
> [<a000000100013c10>] kernel_thread_helper+0x30/0x60
> [<a00000010000a0c0>] start_kernel_thread+0x20/0x40
>
> Does anyone see anything similar on other architectures? Or is ia64 doing
> something "special" here?
Ah, I forgot to test the tty series without the other patches I have
in my bkl removal repository and without CONFIG_TTY_MUTEX.
Does the patch below make this go away? We should probably include
the 'misc' branch of my BKL repository in -next to fix this.
Arnd
--
>From 99b699e56b23775c0c9a131208e1a5e13f6cfad3 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@...db.de>
Date: Mon, 15 Mar 2010 19:00:34 +0100
Subject: [PATCH] init: remove the BKL from startup code
I have shown by code review that no driver takes
the BKL at init time any more, so whatever the
init code was locking against is no longer there
and it is now safe to remove the BKL there.
Signed-off-by: Arnd Bergmann <arnd@...db.de>
diff --git a/init/main.c b/init/main.c
index 3bdb152..81821e1 100644
--- a/init/main.c
+++ b/init/main.c
@@ -434,7 +434,6 @@ static noinline void __init_refok rest_init(void)
rcu_read_lock();
kthreadd_task = find_task_by_pid_ns(pid, &init_pid_ns);
rcu_read_unlock();
- unlock_kernel();
/*
* The boot idle thread must execute schedule()
@@ -555,7 +554,6 @@ asmlinkage void __init start_kernel(void)
* Interrupts are still disabled. Do necessary setups, then
* enable them
*/
- lock_kernel();
tick_init();
boot_cpu_init();
page_address_init();
@@ -819,7 +817,6 @@ static noinline int init_post(void)
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
free_initmem();
- unlock_kernel();
mark_rodata_ro();
system_state = SYSTEM_RUNNING;
numa_default_policy();
@@ -855,8 +852,6 @@ static noinline int init_post(void)
static int __init kernel_init(void * unused)
{
- lock_kernel();
-
/*
* init can allocate pages on any node
*/
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 086d363..8047ca5 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -734,13 +734,6 @@ __acquires(kernel_lock)
return -1;
}
- /*
- * When this gets called we hold the BKL which means that
- * preemption is disabled. Various trace selftests however
- * need to disable and enable preemption for successful tests.
- * So we drop the BKL here and grab it after the tests again.
- */
- unlock_kernel();
mutex_lock(&trace_types_lock);
tracing_selftest_running = true;
@@ -822,7 +815,6 @@ __acquires(kernel_lock)
#endif
out_unlock:
- lock_kernel();
return ret;
}
--
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