From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: lkp@lists.01.org
Subject: Re: [printk] 34578dc67f: EIP is at vprintk_emit+0x1ea/0x600
Date: Wed, 02 Mar 2016 19:41:59 +0900 [thread overview]
Message-ID: <20160302104159.GA646@swordfish> (raw)
In-Reply-To: <20160302103006.GB3166@pathway.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]
On (03/02/16 11:30), Petr Mladek wrote:
> On Thu 2016-02-25 14:10:05, Sergey Senozhatsky wrote:
> > CONFIG_PREEMPT_NONE=y
> > # CONFIG_PREEMPT_VOLUNTARY is not set
> > # CONFIG_PREEMPT is not set
> > CONFIG_PREEMPT_COUNT=y
>
> I was curious why your patch actually did not help to avoid the
> softlockup. The infinite printk loop was called in a safe context,
> CONFIG_PREEMPT_COUNT=y, so it did set console_may_schedule = 1.
>
> But it never got console_sem, never called console_unlock()
> and never called cond_resched() there. So, it never got preempted
> in the PREEMPT_NONE kernel. The console_sem was owned by
> another process that was busy handling the flood of messages.
>
> Note that the infinite cycle calling printk() might be interrupted anywhere
> by the NMI watchdog. It explains why the original report pointed
> at the beginning of the printk. It was not a deadlock.
> I got the softlockup on random locations here.
>
> Also it is not the classic softlockup in console_unlock().
> The process handling the console actually could sleep if it
> has console_may_schedule = 1. This is why console_unlock()
> did not appeared in the softlockup backtrace.
>
>
> Conclusion:
>
> Sergey is correct and his patches are innocent here.
thank you, Petr!
> Sergey, if you send the fix for
> of_unittest_destroy_tracked_overlays(), please add me into CC.
of course, will try to send it out tonight.
> PS: I am sorry for the noise and that it took me so long to shake my
> head around this problem. Thanks a lot for patience.
no problem at all. thank you. the more we double check it - the better.
-ss
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky@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: Wed, 2 Mar 2016 19:41:59 +0900 [thread overview]
Message-ID: <20160302104159.GA646@swordfish> (raw)
In-Reply-To: <20160302103006.GB3166@pathway.suse.cz>
On (03/02/16 11:30), Petr Mladek wrote:
> On Thu 2016-02-25 14:10:05, Sergey Senozhatsky wrote:
> > CONFIG_PREEMPT_NONE=y
> > # CONFIG_PREEMPT_VOLUNTARY is not set
> > # CONFIG_PREEMPT is not set
> > CONFIG_PREEMPT_COUNT=y
>
> I was curious why your patch actually did not help to avoid the
> softlockup. The infinite printk loop was called in a safe context,
> CONFIG_PREEMPT_COUNT=y, so it did set console_may_schedule = 1.
>
> But it never got console_sem, never called console_unlock()
> and never called cond_resched() there. So, it never got preempted
> in the PREEMPT_NONE kernel. The console_sem was owned by
> another process that was busy handling the flood of messages.
>
> Note that the infinite cycle calling printk() might be interrupted anywhere
> by the NMI watchdog. It explains why the original report pointed
> at the beginning of the printk. It was not a deadlock.
> I got the softlockup on random locations here.
>
> Also it is not the classic softlockup in console_unlock().
> The process handling the console actually could sleep if it
> has console_may_schedule = 1. This is why console_unlock()
> did not appeared in the softlockup backtrace.
>
>
> Conclusion:
>
> Sergey is correct and his patches are innocent here.
thank you, Petr!
> Sergey, if you send the fix for
> of_unittest_destroy_tracked_overlays(), please add me into CC.
of course, will try to send it out tonight.
> PS: I am sorry for the noise and that it took me so long to shake my
> head around this problem. Thanks a lot for patience.
no problem at all. thank you. the more we double check it - the better.
-ss
next prev parent reply other threads:[~2016-03-02 10:41 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
2016-02-24 15:12 ` [lkp] " 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 [this message]
2016-03-02 10:41 ` 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=20160302104159.GA646@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.