From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: lkp@lists.01.org
Subject: Re: [printk] 34578dc67f: EIP is at vprintk_emit+0x1ea/0x600
Date: Thu, 25 Feb 2016 00:12:42 +0900 [thread overview]
Message-ID: <20160224151242.GA2254@swordfish> (raw)
In-Reply-To: <20160224125022.GA516@swordfish>
[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]
On (02/24/16 21:50), Sergey Senozhatsky wrote:
> On (02/24/16 12:46), Petr Mladek wrote:
> [..]
> > > and you get the NMI watchdog softlockup because you have a whole bunch of
> > >
> > > "of_overlay_destroy: Could not find overlay #6"
> > > "### dt-test ### of_unittest_destroy_tracked_overlays: overlay destroy failed for #6"
> > >
> > > messages to print. seems that somehitng just pushes them in a loop.
> > > there are too many of them:
> >
> > This sounds like a reasonable explanation. It seems that
> > of_unittest_destroy_tracked_overlays() really ended in an infinite
> > loop.
> >
> > But I am still curious why the softlookup points to
> >
> > [ 33.497718] EIP is at vprintk_emit+0x1ea/0x600
> >
> > Also there is on the stack
> >
> > [ 33.497741] [<c068e712>] vprintk_default+0x32/0x40
> > [ 33.497741] [<c068e712>] vprintk_default+0x32/0x40
> > [ 33.497744] [<c06fdf6e>] printk+0x11/0x13
> > [ 33.497744] [<c06fdf6e>] printk+0x11/0x13
> > [ 33.497748] [<c0df5eec>] of_unittest_overlay+0x8d1/0x900
> > [ 33.497748] [<c0df5eec>] of_unittest_overlay+0x8d1/0x900
> > [ 33.497750] [<c0df6b1f>] of_unittest+0xc04/0xc2d
> > [ 33.497750] [<c0df6b1f>] of_unittest+0xc04/0xc2d
> >
> > I would expect that the soft lookup happens in console_unlock()
> > called with IRQs disabled. It seems to me that of_unittest_overlay()
> > is called with IRQs enabled.
hm... both of the logbuf_lock/irq reqions in vprintk_emit/console_unlock
are not modified by the patch set. there is, however, one thing that has
changed -- additional console_cont_flush() calls, which does spin_lock_irq
logbuf_lock and spin_unlock_irq logbuf_lock.
> > I want to be sure that the patch in printk() did not introduce
> > a deadlock that is visible only under a high printk load.
I'll do more tests, certainly.
-ss
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
kernel test robot <ying.huang@linux.intel.com>,
lkp@01.org, Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
devicetree@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Calvin Owens <calvinowens@fb.com>,
Dave Jones <davej@codemonkey.org.uk>,
Kyle McMartin <kyle@kernel.org>, Tejun Heo <tj@kernel.org>,
Jan Kara <jack@suse.com>, Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [lkp] [printk] 34578dc67f: EIP is at vprintk_emit+0x1ea/0x600
Date: Thu, 25 Feb 2016 00:12:42 +0900 [thread overview]
Message-ID: <20160224151242.GA2254@swordfish> (raw)
In-Reply-To: <20160224125022.GA516@swordfish>
On (02/24/16 21:50), Sergey Senozhatsky wrote:
> On (02/24/16 12:46), Petr Mladek wrote:
> [..]
> > > and you get the NMI watchdog softlockup because you have a whole bunch of
> > >
> > > "of_overlay_destroy: Could not find overlay #6"
> > > "### dt-test ### of_unittest_destroy_tracked_overlays: overlay destroy failed for #6"
> > >
> > > messages to print. seems that somehitng just pushes them in a loop.
> > > there are too many of them:
> >
> > This sounds like a reasonable explanation. It seems that
> > of_unittest_destroy_tracked_overlays() really ended in an infinite
> > loop.
> >
> > But I am still curious why the softlookup points to
> >
> > [ 33.497718] EIP is at vprintk_emit+0x1ea/0x600
> >
> > Also there is on the stack
> >
> > [ 33.497741] [<c068e712>] vprintk_default+0x32/0x40
> > [ 33.497741] [<c068e712>] vprintk_default+0x32/0x40
> > [ 33.497744] [<c06fdf6e>] printk+0x11/0x13
> > [ 33.497744] [<c06fdf6e>] printk+0x11/0x13
> > [ 33.497748] [<c0df5eec>] of_unittest_overlay+0x8d1/0x900
> > [ 33.497748] [<c0df5eec>] of_unittest_overlay+0x8d1/0x900
> > [ 33.497750] [<c0df6b1f>] of_unittest+0xc04/0xc2d
> > [ 33.497750] [<c0df6b1f>] of_unittest+0xc04/0xc2d
> >
> > I would expect that the soft lookup happens in console_unlock()
> > called with IRQs disabled. It seems to me that of_unittest_overlay()
> > is called with IRQs enabled.
hm... both of the logbuf_lock/irq reqions in vprintk_emit/console_unlock
are not modified by the patch set. there is, however, one thing that has
changed -- additional console_cont_flush() calls, which does spin_lock_irq
logbuf_lock and spin_unlock_irq logbuf_lock.
> > I want to be sure that the patch in printk() did not introduce
> > a deadlock that is visible only under a high printk load.
I'll do more tests, certainly.
-ss
next prev parent reply other threads:[~2016-02-24 15:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160223131538.GA2048@swordfish>
2016-02-23 15:53 ` [printk] 34578dc67f: EIP is at vprintk_emit+0x1ea/0x600 Sergey Senozhatsky
2016-02-23 15:53 ` [lkp] " Sergey Senozhatsky
2016-02-24 1:19 ` Sergey Senozhatsky
2016-02-24 1:19 ` [lkp] " Sergey Senozhatsky
2016-02-24 1:19 ` Sergey Senozhatsky
2016-02-24 11:46 ` Petr Mladek
2016-02-24 11:46 ` [lkp] " Petr Mladek
2016-02-24 11:46 ` Petr Mladek
2016-02-24 12:50 ` Sergey Senozhatsky
2016-02-24 12:50 ` [lkp] " Sergey Senozhatsky
2016-02-24 12:50 ` Sergey Senozhatsky
2016-02-24 15:12 ` Sergey Senozhatsky [this message]
2016-02-24 15:12 ` Sergey Senozhatsky
2016-02-25 5:10 ` Sergey Senozhatsky
2016-02-25 5:10 ` [lkp] " Sergey Senozhatsky
2016-02-25 5:10 ` Sergey Senozhatsky
2016-03-02 10:30 ` Petr Mladek
2016-03-02 10:30 ` [lkp] " Petr Mladek
2016-03-02 10:41 ` Sergey Senozhatsky
2016-03-02 10:41 ` [lkp] " Sergey Senozhatsky
2016-02-23 0:55 kernel test robot
2016-02-23 0:55 ` [lkp] " kernel test robot
2016-02-23 16:55 ` Petr Mladek
2016-02-23 16:55 ` [lkp] " Petr Mladek
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=20160224151242.GA2254@swordfish \
--to=sergey.senozhatsky@gmail.com \
--cc=lkp@lists.01.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 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.