lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 16 Feb 2017 11:13:03 -0800 From: Tony Lindgren <tony@...mide.com> To: Sergey Senozhatsky <sergey.senozhatsky@...il.com> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>, Petr Mladek <pmladek@...e.com>, Steven Rostedt <rostedt@...dmis.org>, Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...ysocki.net>, linux-pm@...r.kernel.org, Russell King <rmk@...linux.org.uk> Subject: Re: Regression in next with use printk_safe buffers in printk * Sergey Senozhatsky <sergey.senozhatsky@...il.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
Powered by blists - more mailing lists