From: Tony Lindgren <tony@atomide.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-pm@vger.kernel.org
Subject: Re: Regression in next with use printk_safe buffers in printk
Date: Tue, 14 Feb 2017 08:54:52 -0800 [thread overview]
Message-ID: <20170214165451.GI21809@atomide.com> (raw)
In-Reply-To: <20170214160140.GA401@tigerII.localdomain>
* Sergey Senozhatsky <sergey.senozhatsky@gmail.com> [170214 08:03]:
> Hello,
>
> Cc Rafael, just in case
>
> On (02/13/17 10:59), Tony Lindgren wrote:
> > Looks like commit f975237b7682 ("printk: use printk_safe buffers in
> > printk") causes "possible circular locking dependency detected " for
> > me on the first suspend.
>
> thanks for the report.
>
> > Reverting the following four patches in next makes it go away:
> >
> > d9c23523ed98 ("printk: drop call_console_drivers() unused param")
> > de6fcbdb68b2 ("printk: convert the rest to printk-safe")
> > 8b1742c9c207 ("printk: remove zap_locks() function")
> > f975237b7682 ("printk: use printk_safe buffers in printk")
>
>
> these patches basically just enable locked where it previously was
> forcibly turned off. no timekeeping/pm/sched/etc code was modified.
> can you share the link where Peter pointed out that this might be
> caused by printk() changes?
Oh sorry I should have been more specific. Not much there to share,
I got redirected over to Peter's department in a private email thread
while chasing this issue. So that was just Peter's comment looking at
the log output.
> timekeeping_resume()
> lock timekeeper_lock
> lock tk_core
> tk_debug_account_sleep_time()
> printk() << lockdep was disabled here before
> try_to_wake_up()
> lock_hrtimer_base() ##hrtimer_bases.lock
Yeah above seems describe what changed, so your patch makes sense.
> shouldn't tk_debug_account_sleep_time() do printk_deferred() instead of
> 'normal' printk()?
> printk() calls from under timekeeping seqlock are not safe, aren't they?
> and tk_debug_account_sleep_time() is under tk_core seq lock.
>
> IOW, replace pr_info() in tk_debug_account_sleep_time() with something
> like this
>
> printk_deferred(KERN_INFO "Suspended for %lld.%03lu seconds\n",
> (s64)t->tv_sec, t->tv_nsec / NSEC_PER_MSEC);
Your patch below fixes the issue for me thanks. I had to apply it manually
though as tabs got replaced by spaces probably by some mail daemons.
Regards,
Tony
> ---
>
> diff --git a/kernel/time/timekeeping_debug.c b/kernel/time/timekeeping_debug.c
> index ca9fb800336b..b8f7146c3538 100644
> --- a/kernel/time/timekeeping_debug.c
> +++ b/kernel/time/timekeeping_debug.c
> @@ -75,7 +75,8 @@ void tk_debug_account_sleep_time(struct timespec64 *t)
> int bin = min(fls(t->tv_sec), NUM_BINS-1);
>
> sleep_time_bin[bin]++;
> - pr_info("Suspended for %lld.%03lu seconds\n", (s64)t->tv_sec,
> + printk_deferred(KERN_INFO "Suspended for %lld.%03lu seconds\n",
> + (s64)t->tv_sec,
> t->tv_nsec / NSEC_PER_MSEC);
> }
>
>
next prev parent reply other threads:[~2017-02-14 16:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 18:59 Regression in next with use printk_safe buffers in printk Tony Lindgren
2017-02-14 16:01 ` Sergey Senozhatsky
2017-02-14 16:18 ` Peter Zijlstra
2017-02-14 16:56 ` Sergey Senozhatsky
2017-02-14 17:03 ` Tony Lindgren
2017-02-15 4:44 ` Sergey Senozhatsky
2017-02-14 18:29 ` Peter Zijlstra
2017-02-15 4:49 ` Sergey Senozhatsky
2017-02-14 16:54 ` Tony Lindgren [this message]
2017-02-15 18:01 ` Tony Lindgren
2017-02-16 1:31 ` Sergey Senozhatsky
2017-02-16 4:03 ` Tony Lindgren
2017-02-16 4:25 ` Sergey Senozhatsky
2017-02-16 15:10 ` Tony Lindgren
2017-02-16 16:31 ` Sergey Senozhatsky
2017-02-16 19:13 ` Tony Lindgren
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=20170214165451.GI21809@atomide.com \
--to=tony@atomide.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
/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.