From: Jan Kara <jack@suse.cz>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
"Shevchenko, Andriy" <andriy.shevchenko@intel.com>,
Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: lockdep warning after recent cleanup in console code
Date: Mon, 28 Apr 2014 19:51:39 +0200 [thread overview]
Message-ID: <20140428175139.GD9091@quack.suse.cz> (raw)
In-Reply-To: <20140428134331.68771bf7@gandalf.local.home>
On Mon 28-04-14 13:43:31, Steven Rostedt wrote:
> Things have changed with regard to printk() in linux-next. Now it
> appears that lockdep is going haywire over it. I don't understand the
> exact reason for the lockdep_off() and lockdep_on() logic that is in
> printk(), but it obviously seems to be causing issues with the new
> changes.
>
> Care to take a look?
The obvious cause is that I moved lockdep_on() somewhat earlier in
vprintk_emit() so lockdep now covers more of printk code. And apparently
something is wrong there...
Honza
>
> -- Steve
>
>
> On Mon, 28 Apr 2014 16:35:26 +0000
> "Shevchenko, Andriy" <andriy.shevchenko@intel.com> wrote:
>
> > Hei!
> >
> > During weekend the linux-next was being broken by introducing a lockdep
> > warning in the console code
> >
> > [ 0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000ffffffff]
> > reserved
> > [ 0.000000]
> > [ 0.000000] =============================================
> > [ 0.000000] [ INFO: possible recursive locking detected ]
> > [ 0.000000] 3.15.0-rc2-next-20140428-00030-gd3550d8 #38 Not tainted
> > [ 0.000000] ---------------------------------------------
> > [ 0.000000] swapper/0 is trying to acquire lock:
> > [ 0.000000] (console_lock){......}, at: [<c10728cc>]
> > register_console+0x15e/0x295
> > [ 0.000000]
> > [ 0.000000] but task is already holding lock:
> > [ 0.000000] (console_lock){......}, at: [<c1071e7a>] vprintk_emit
> > +0x381/0x3ea
> > [ 0.000000]
> > [ 0.000000] other info that might help us debug this:
> > [ 0.000000] Possible unsafe locking scenario:
> > [ 0.000000]
> > [ 0.000000] CPU0
> > [ 0.000000] ----
> > [ 0.000000] lock(console_lock);
> > [ 0.000000] lock(console_lock);
> > [ 0.000000]
> > [ 0.000000] *** DEADLOCK ***
> > [ 0.000000]
> > [ 0.000000] May be due to missing lock nesting notation
> > [ 0.000000]
> > [ 0.000000] 3 locks held by swapper/0:
> > [ 0.000000] #0: (console_lock){......}, at: [<c1071e7a>]
> > vprintk_emit+0x381/0x3ea
> > [ 0.000000] #1: (console_lock){......}, at: [<c1071e7a>]
> > vprintk_emit+0x381/0x3ea
> > [ 0.000000] #2: (console_lock){......}, at: [<c1071e7a>]
> > vprintk_emit+0x381/0x3ea
> > [ 0.000000]
> > [ 0.000000] stack backtrace:
> > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> > 3.15.0-rc2-next-20140428-00030-gd3550d8 #38
> > [ 0.000000] 00000000 00000000 c186de1c c15878ae c1daf840 c186de88
> > c106c154 c1794d9d
> > [ 0.000000] c17958f7 c1794c9c 0000002a 00000000 00000000 c1daf840
> > c1983700 00000080
> > [ 0.000000] 04002001 c187a0b0 00000000 c1879ba0 c1879b40 c1879b40
> > 00200046 00000000
> > [ 0.000000] Call Trace:
> > [ 0.000000] [<c15878ae>] dump_stack+0x49/0x73
> > [ 0.000000] [<c106c154>] __lock_acquire+0xb31/0xc7c
> > [ 0.000000] [<c106c33b>] lock_acquire+0x9c/0x111
> > [ 0.000000] [<c10728cc>] ? register_console+0x15e/0x295
> > [ 0.000000] [<c10707dd>] console_lock+0x41/0x46
> > [ 0.000000] [<c10728cc>] ? register_console+0x15e/0x295
> > [ 0.000000] [<c10728cc>] register_console+0x15e/0x295
> > [ 0.000000] [<c1582f80>] early_console_register+0x33/0x35
> > [ 0.000000] [<c1910411>] setup_early_printk+0x144/0x151
> > [ 0.000000] [<c19013f6>] do_early_param+0x41/0x73
> > [ 0.000000] [<c19013b5>] ? loglevel+0x2c/0x2c
> > [ 0.000000] [<c104c766>] parse_args+0x24f/0x307
> > [ 0.000000] [<c19013b5>] ? loglevel+0x2c/0x2c
> > [ 0.000000] [<c190169d>] parse_early_options+0x1c/0x21
> > [ 0.000000] [<c190169d>] ? parse_early_options+0x1c/0x21
> > [ 0.000000] [<c19013b5>] ? loglevel+0x2c/0x2c
> > [ 0.000000] [<c19016cc>] parse_early_param+0x2a/0x36
> > [ 0.000000] [<c19042c0>] setup_arch+0x3c9/0xc55
> > [ 0.000000] [<c1071ebe>] ? vprintk_emit+0x3c5/0x3ea
> > [ 0.000000] [<c1584869>] ? printk+0x28/0x2d
> > [ 0.000000] [<c1901754>] start_kernel+0x72/0x305
> > [ 0.000000] [<c19012b4>] i386_start_kernel+0x82/0x86
> > [ 0.000000] bootconsole [earlyhsu0] enabled
> >
> > Bisecting shows the culprit (which I guessed before), namely commit
> > 5dc90cb49691755faaad2a395d297d0162075eca ("printk: enable interrupts
> > before calling console_trylock_for_printk()").
> >
> > Following patch helps me, but I'm not familiar with console locking
> > scheme, I believe there is a better solution.
> >
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -1700,8 +1700,10 @@ asmlinkage int vprintk_emit(int facility, int
> > level,
> > * The release will print out buffers and wake up /dev/kmsg and
> > syslog()
> > * users.
> > */
> > + lockdep_off();
> > if (console_trylock_for_printk())
> > console_unlock();
> > + lockdep_on();
> > preempt_enable();
> >
> > return printed_len;
> >
> >
>
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2014-04-28 20:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-28 16:35 lockdep warning after recent cleanup in console code Shevchenko, Andriy
2014-04-28 17:43 ` Steven Rostedt
2014-04-28 17:51 ` Jan Kara [this message]
2014-04-28 18:14 ` Steven Rostedt
2014-04-28 19:24 ` Jan Kara
2014-04-28 19:36 ` Steven Rostedt
2014-04-28 20:13 ` Jan Kara
2014-04-29 8:38 ` Andy Shevchenko
2014-04-29 21:07 ` Jan Kara
2014-04-30 8:12 ` Andy Shevchenko
2014-04-28 18:31 ` Peter Zijlstra
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=20140428175139.GD9091@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox