From: Tony Lindgren <tony@atomide.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
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,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-pm@vger.kernel.org, Russell King <rmk@armlinux.org.uk>
Subject: Re: Regression in next with use printk_safe buffers in printk
Date: Thu, 16 Feb 2017 11:13:03 -0800 [thread overview]
Message-ID: <20170216191302.GZ21809@atomide.com> (raw)
In-Reply-To: <20170216163148.GA22354@tigerII.localdomain>
* Sergey Senozhatsky <sergey.senozhatsky@gmail.com> [170216 08:33]:
> On (02/16/17 07:10), Tony Lindgren wrote:
> [..]
> > > > > [..]
> > > > > > Below is another issue I noticed caused by commit f975237b7682 that
> > > > > > I noticed during booting.
> > > > >
> > > > > do you mean that with f975237b7682 you _always_ see that illegal RCU
> > > > > usage warning?
> > > >
> > > > Yeah on every boot on devices using cpuidle_coupled.
> > >
> > > does this mean that with the printk-safe patches reverted
> > > (so, basically, the same conditions module 4 printk patches)
> > > you don't see illegal RCU usage reports? at the moment I can't
> > > see any connection between f975237b7682 and RCU usage from idle CPU.
> >
> > Yes reverting those four patches I listed earlier also makes it go
> > away.
>
> aha... so, the previous RCU warning was simply suppressed by lockdep_off()
> that we used to have in printk().
>
>
> RCU dereference check
>
> #define __rcu_dereference_check(p, c, space) \
> ({ \
> /* Dependency order vs. p above. */ \
> typeof(*p) *________p1 = (typeof(*p) *__force)lockless_dereference(p); \
> RCU_LOCKDEP_WARN(!(c), "suspicious rcu_dereference_check() usage"); \
> rcu_dereference_sparse(p, space); \
> ((typeof(*p) __force __kernel *)(________p1)); \
> })
>
>
> where RCU_LOCKDEP_WARN() that prints "suspicious rcu_dereference_check() usage"
> is
>
>
> #define RCU_LOCKDEP_WARN(c, s) \
> do { \
> static bool __section(.data.unlikely) __warned; \
> if (debug_lockdep_rcu_enabled() && !__warned && (c)) { \
> __warned = true; \
> lockdep_rcu_suspicious(__FILE__, __LINE__, s); \
> } \
> } while (0)
>
>
>
> where debug_lockdep_rcu_enabled()
>
> int notrace debug_lockdep_rcu_enabled(void)
> {
> return rcu_scheduler_active != RCU_SCHEDULER_INACTIVE && debug_locks &&
> current->lockdep_recursion == 0;
> }
>
> depends on lockdep state. and we just used to have
> 'current->lockdep_recursion != 0' here, because of lockdep_off()
> in printk() around console_unlock(), which increments ->lockdep_recursion.
>
> now we have lockdep enabled and the ->lockdep_recursion == 0.
>
>
> so the RCU warning is valid and I need to Cc stable on that _rcuidle
> patch, the tracepoint is pretty old. it's from 3.4
OK thanks for checking why it changed.
Regards,
Tony
prev parent reply other threads:[~2017-02-16 19:13 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
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 [this message]
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=20170216191302.GZ21809@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=rmk@armlinux.org.uk \
--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.