public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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