Miscellaneous fixes for 4.3
Subsystems (15)
cover Miscellaneous fixes for 4.3
Hello!
This series contains miscellaneous fixes.
1. Drop RCU_USER_QS in favor of NO_HZ_FULL.
2. Deinline rcu_read_lock_sched_held() even in kernels built with
CONFIG_DEBUG_LOCK_ALLOC=y, courtesy of Denys Vlasenko.
3. Change srcu_readers_active()'s return type to bool, courtesy
of Nicholas Mc Guire.
4. Add RCU-sched flavors get-state/cond-sync functions, namely
get_state_synchronize_sched() and cond_synchronize_sched().
5. Hide RCU_NOCB_CPU behind RCU_EXPERT, arriving at fully
automated Kconfig setup for RCU.
6. Use WRITE_ONCE in RCU_INIT_POINTER, courtesy of Peter Zijlstra.
7. Fix obsolete priority-boosting comment.
8. Create a synchronize_rcu_mult() to allow overlapped synchronous
grace periods.
9. Use synchronize_rcu_mult() to make _cpu_down() wait for its
RCU and RCU-sched grace periods concurrently.
10. Make rcu_is_watching() really be notrace, courtesy of =
Alexei Starovoitov.
11. Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN().
12. Fix backwards RCU_LOCKDEP_WARN() in synchronize_rcu_tasks().
13. Clarify CONFIG_RCU_EQS_DEBUG help text.
14. Update RCU MAINTAINERS email address, courtesy of Lai Jiangshan.
15. Make checkpatch.pl warn on expedited RCU grace periods.
16. Don't disable CPU hotplug during OOM notifiers.
Thanx, Paul
------------------------------------------------------------------------
b/Documentation/RCU/whatisRCU.txt | 2 b/MAINTAINERS | 6 - b/arch/x86/kernel/cpu/mcheck/mce.c | 6 - b/arch/x86/kernel/traps.c | 2 b/drivers/base/power/opp.c | 4 - b/include/linux/fdtable.h | 4 - b/include/linux/rcupdate.h | 144 ++++++++++++++++++++----------------- b/include/linux/rcutiny.h | 10 ++ b/include/linux/rcutree.h | 2 b/include/linux/types.h | 3 b/init/Kconfig | 10 -- b/kernel/cgroup.c | 4 - b/kernel/cpu.c | 10 +- b/kernel/pid.c | 5 - b/kernel/rcu/rcutorture.c | 2 b/kernel/rcu/srcu.c | 15 ++- b/kernel/rcu/tiny.c | 8 +- b/kernel/rcu/tree.c | 92 ++++++++++++++++++----- b/kernel/rcu/tree_plugin.h | 13 +-- b/kernel/rcu/update.c | 92 ++++++++++++++++++++--- b/kernel/sched/core.c | 8 +- b/kernel/time/Kconfig | 2 b/kernel/workqueue.c | 20 ++--- b/lib/Kconfig.debug | 2 b/scripts/checkpatch.pl | 19 ++++ b/security/device_cgroup.c | 6 - 26 files changed, 322 insertions(+), 169 deletions(-)
PATCH 1/16 rcu: Drop RCU_USER_QS in favor of NO_HZ_FULL
From: "Paul E. McKenney" <[email protected]>
The RCU_USER_QS Kconfig parameter is now just a synonym for NO_HZ_FULL, so this commit eliminates RCU_USER_QS, replacing all uses with NO_HZ_FULL.
--- include/linux/rcupdate.h | 4 ++-- init/Kconfig | 9 --------- kernel/rcu/tree.c | 8 ++++---- kernel/time/Kconfig | 2 -- 4 files changed, 6 insertions(+), 17 deletions(-)
include/linux/rcupdate.h +2 -2
@@ -309,7 +309,7 @@ static inline void rcu_sysrq_end(void) }#endif /* #else #ifdef CONFIG_RCU_STALL_COMMON */ -#ifdef CONFIG_RCU_USER_QS +#ifdef CONFIG_NO_HZ_FULL void rcu_user_enter (void );void rcu_user_exit (void );#else
@@ -317,7 +317,7 @@ static inline void rcu_user_enter(void) { }static inline void rcu_user_exit (void ) { }static inline void rcu_user_hooks_switch (struct task_struct *prev,struct task_struct *next) { } -#endif /* CONFIG_RCU_USER_QS */ +#endif /* CONFIG_NO_HZ_FULL */ #ifdef CONFIG_RCU_NOCB_CPU void rcu_init_nohz (void );
init/Kconfig +0 -9
@@ -538,15 +538,6 @@ config RCU_STALL_COMMON config CONTEXT_TRACKING bool -config RCU_USER_QS - bool - help - This option sets hooks on kernel / userspace boundaries and - puts RCU in extended quiescent state when the CPU runs in - userspace. It means that when a CPU runs in userspace, it is - excluded from the global RCU state machine and thus doesn't - try to keep the timer tick on for RCU. - config CONTEXT_TRACKING_FORCE bool "Force context tracking" depends on CONTEXT_TRACKING
kernel/rcu/tree.c +4 -4
@@ -701,7 +701,7 @@ void rcu_idle_enter(void) }EXPORT_SYMBOL_GPL (rcu_idle_enter); -#ifdef CONFIG_RCU_USER_QS +#ifdef CONFIG_NO_HZ_FULL /** * rcu_user_enter - inform RCU that we are resuming userspace. *
@@ -714,7 +714,7 @@ void rcu_user_enter(void) {rcu_eqs_enter (1 ); } -#endif /* CONFIG_RCU_USER_QS */ +#endif /* CONFIG_NO_HZ_FULL */ /** * rcu_irq_exit - inform RCU that current CPU is exiting irq towards idle
@@ -828,7 +828,7 @@ void rcu_idle_exit(void) }EXPORT_SYMBOL_GPL (rcu_idle_exit); -#ifdef CONFIG_RCU_USER_QS +#ifdef CONFIG_NO_HZ_FULL /** * rcu_user_exit - inform RCU that we are exiting userspace. *
@@ -839,7 +839,7 @@ void rcu_user_exit(void) {rcu_eqs_exit (1 ); } -#endif /* CONFIG_RCU_USER_QS */ +#endif /* CONFIG_NO_HZ_FULL */ /** * rcu_irq_enter - inform RCU that current CPU is entering irq away from idle
kernel/time/Kconfig +0 -2
@@ -92,12 +92,10 @@ config NO_HZ_FULL depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS # We need at least one periodic CPU for timekeeping depends on SMP - # RCU_USER_QS dependency depends on HAVE_CONTEXT_TRACKING # VIRT_CPU_ACCOUNTING_GEN dependency depends on HAVE_VIRT_CPU_ACCOUNTING_GEN select NO_HZ_COMMON - select RCU_USER_QS select RCU_NOCB_CPU select VIRT_CPU_ACCOUNTING_GEN select IRQ_WORK
Signature · 1 line
1.8.1.5
PATCH 2/16 rcu: Deinline rcu_read_lock_sched_held() if DEBUG_LOCK_ALLOC
From: Denys Vlasenko <[email protected]>
DEBUG_LOCK_ALLOC=y is not a production setting, but it is not very unusual either. Many developers routinely use kernels built with it enabled.
Apart from being selected by hand, it is also auto-selected by PROVE_LOCKING "Lock debugging: prove locking correctness" and LOCK_STAT "Lock usage statistics" config options. LOCK STAT is necessary for "perf lock" to work.
I wouldn't spend too much time optimizing it, but this particular function has a very large cost in code size: when it is deinlined, code size decreases by 830,000 bytes:
text data bss dec hex filename
85674192 22294776 20627456 128596424 7aa39c8 vmlinux.before 84837612 22294424 20627456 127759492 79d7484 vmlinux
(with this config: http://busybox.net/~vda/kernel_config)
--- include/linux/rcupdate.h | 40 ++------------------------------------- kernel/rcu/update.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+), 38 deletions(-)
include/linux/rcupdate.h +2 -38
@@ -469,46 +469,10 @@ int rcu_read_lock_bh_held(void);* If CONFIG_DEBUG_LOCK_ALLOC is selected, returns nonzero iff in an * RCU-sched read-side critical section. In absence of * CONFIG_DEBUG_LOCK_ALLOC, this assumes we are in an RCU-sched read-side -* critical section unless it can prove otherwise. Note that disabling -* of preemption (including disabling irqs) counts as an RCU-sched -* read-side critical section. This is useful for debug checks in functions -* that required that they be called within an RCU-sched read-side -* critical section. -* -* Check debug_lockdep_rcu_enabled() to prevent false positives during boot -* and while lockdep is disabled. -* -* Note that if the CPU is in the idle loop from an RCU point of -* view (ie: that we are in the section between rcu_idle_enter() and -* rcu_idle_exit()) then rcu_read_lock_held() returns false even if the CPU -* did an rcu_read_lock(). The reason for this is that RCU ignores CPUs -* that are in such a section, considering these as in extended quiescent -* state, so such a CPU is effectively never in an RCU read-side critical -* section regardless of what RCU primitives it invokes. This state of -* affairs is required --- we need to keep an RCU-free window in idle -* where the CPU may possibly enter into low power mode. This way we can -* notice an extended quiescent state to other CPUs that started a grace -* period. Otherwise we would delay any grace period as long as we run in -* the idle task. -* -* Similarly, we avoid claiming an SRCU read lock held if the current -* CPU is offline. +* critical section unless it can prove otherwise. */ #ifdef CONFIG_PREEMPT_COUNT -static inline int rcu_read_lock_sched_held (void ) -{ -int lockdep_opinion =0 ; - -if (!debug_lockdep_rcu_enabled ()) -return 1 ; -if (!rcu_is_watching ()) -return 0 ; -if (!rcu_lockdep_current_cpu_online ()) -return 0 ; -if (debug_locks) - lockdep_opinion =lock_is_held (&rcu_sched_lock_map); -return lockdep_opinion ||preempt_count () !=0 ||irqs_disabled (); -} +int rcu_read_lock_sched_held (void );#else /* #ifdef CONFIG_PREEMPT_COUNT */ static inline int rcu_read_lock_sched_held (void ) {
kernel/rcu/update.c +49 -0
55 lines not on this page · raw message
Signature · 1 line
1.8.1.5
PATCH 3/16 rcu: Change return type to bool
In reply to Paul E. McKenneyFrom: Nicholas Mc Guire <[email protected]>
Type-checking coccinelle spatches are being used to locate type mismatches between function signatures and return values in this case this produced:./kernel/rcu/srcu.c:271 WARNING: return of wrong type
int != unsigned long,
srcu_readers_active() returns an int that is the sum of per_cpu unsigned long but the only user is cleanup_srcu_struct() which is using it as a boolean (condition) to see if there is any readers rather than actually using the approximate number of readers. The theoretically possible unsigned long overflow case does not need to be handled explicitly - if we had 4G++ readers then something else went wrong a long time ago.
proposal: change the return type to boolean. The function name is left
unchanged as it fits the naming expectation for a boolean.
patch was compile tested for x86_64_defconfig (implies CONFIG_SRCU=y)
patch is against 4.1-rc5 (localversion-next is -next-20150525)
--- kernel/rcu/srcu.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
kernel/rcu/srcu.c +3 -2
@@ -252,14 +252,15 @@ static bool srcu_readers_active_idx_check(struct srcu_struct *sp, int idx) }/** -* srcu_readers_active - returns approximate number of readers. +* srcu_readers_active - returns true if there are readers. and false +* otherwise * @sp: which srcu_struct to count active readers (holding srcu_read_lock). * * Note that this is not an atomic primitive, and can therefore suffer * severe errors when invoked on an active srcu_struct. That said, it * can be useful as an error check at cleanup time. */ -static int srcu_readers_active (struct srcu_struct *sp) +static bool srcu_readers_active (struct srcu_struct *sp) {int cpu;unsigned long sum =0 ;
Signature · 1 line
1.8.1.5
PATCH 4/16 rcu: Add RCU-sched flavors of get-state and cond-sync
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
The get_state_synchronize_rcu() and cond_synchronize_rcu() functions allow polling for grace-period completion, with an actual wait for a grace period occuring only when cond_synchronize_rcu() is called too soon after the corresponding get_state_synchronize_rcu(). However, these functions work only for vanilla RCU. This commit adds the get_state_synchronize_sched() and cond_synchronize_sched(), which provide the same capability for RCU-sched.
--- include/linux/rcutiny.h | 10 ++++++++++ include/linux/rcutree.h | 2 ++ kernel/rcu/rcutorture.c | 2 ++ kernel/rcu/tree.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 66 insertions(+)
include/linux/rcutiny.h +10 -0
@@ -37,6 +37,16 @@ static inline void cond_synchronize_rcu(unsigned long oldstate)might_sleep (); } +static inline unsigned long get_state_synchronize_sched (void ) +{ +return 0 ; +} + +static inline void cond_synchronize_sched (unsigned long oldstate) +{ +might_sleep (); +} +static inline void rcu_barrier_bh (void ) {wait_rcu_gp (call_rcu_bh);
include/linux/rcutree.h +2 -0
@@ -76,6 +76,8 @@ void rcu_barrier_bh(void);void rcu_barrier_sched (void );unsigned long get_state_synchronize_rcu (void );void cond_synchronize_rcu (unsigned long oldstate); +unsigned long get_state_synchronize_sched (void ); +void cond_synchronize_sched (unsigned long oldstate);extern unsigned long rcutorture_testseq;extern unsigned long rcutorture_vernum;
kernel/rcu/rcutorture.c +2 -0
@@ -635,6 +635,8 @@ static struct rcu_torture_ops sched_ops = { .deferred_free = rcu_sched_torture_deferred_free, .sync = synchronize_sched, .exp_sync = synchronize_sched_expedited, + .get_state = get_state_synchronize_sched, + .cond_sync = cond_synchronize_sched, .call = call_rcu_sched, .cb_barrier = rcu_barrier_sched, .fqs = rcu_sched_force_quiescent_state,
kernel/rcu/tree.c +52 -0
58 lines not on this page · raw message
Signature · 1 line
1.8.1.5
PATCH 5/16 rcu: Hide RCU_NOCB_CPU behind RCU_EXPERT
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
This commit prevents Kconfig from asking the user about RCU_NOCB_CPU unless the user really wants to be asked.
--- init/Kconfig | 1 + 1 file changed, 1 insertion(+)
init/Kconfig +1 -0
@@ -698,6 +698,7 @@ config RCU_BOOST_DELAY config RCU_NOCB_CPU bool "Offload RCU callback processing from boot-selected CPUs" depends on TREE_RCU || PREEMPT_RCU + depends on RCU_EXPERT || NO_HZ_FULL default n help Use this option to reduce OS jitter for aggressive HPC or
Signature · 1 line
1.8.1.5
PATCH 6/16 rcu: Use WRITE_ONCE in RCU_INIT_POINTER
In reply to Paul E. McKenneyFrom: Peter Zijlstra <[email protected]>
For the paranoid amongst us GCC would be in its right to use byte stores to write our NULL value, tell it not to do that.
--- include/linux/rcupdate.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/rcupdate.h +1 -1
@@ -995,7 +995,7 @@ static inline notrace void rcu_read_unlock_sched_notrace(void)#define RCU_INIT_POINTER (p, v) \ do { \ rcu_dereference_sparse(p, __rcu); \ - p = RCU_INITIALIZER(v); \ + WRITE_ONCE(p, RCU_INITIALIZER(v)); \ } while (0)/**
Signature · 1 line
1.8.1.5
PATCH 7/16 rcu: Fix obsolete priority-boosting comment
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
Tasks are no longer migrated to the root rcu_node, so there is no longer any need for a boost kthread for the root rcu_node, and there no longer is such a kthread. This commit therefore fixes the comment in rcu_boost_kthread()'s header to reflect this new reality.
--- kernel/rcu/tree_plugin.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
kernel/rcu/tree_plugin.h +1 -2
@@ -1061,8 +1061,7 @@ static int rcu_boost(struct rcu_node *rnp) }/* -* Priority-boosting kthread. One per leaf rcu_node and one for the -* root rcu_node. +* Priority-boosting kthread, one per leaf rcu_node. */ static int rcu_boost_kthread (void *arg) {
Signature · 1 line
1.8.1.5
PATCH 8/16 rcu: Create a synchronize_rcu_mult()
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
There have been several requests for a primitive that waits for grace periods for several RCU flavors concurrently, so this commit creates it. This is a variadic macro, and you pass in the call_rcu() functions of the flavors of RCU that you wish to wait for.
Note that you cannot pass in call_srcu() for two reasons: (1) This would result in a type mismatch and (2) You need to specify which srcu_struct you want to use. Handle this by creating a wrapper function for your SRCU domain, for example:
void call_srcu_mine(struct rcu_head *head, rcu_callback_t func)
{
call_srcu(&ss_mine, head, func);
}You can then do something like this:
synchronize_rcu_mult(call_srcu_mine, call_rcu, call_rcu_sched);
--- include/linux/rcupdate.h | 35 +++++++++++++++++++++++++++++++---- include/linux/types.h | 3 +++ kernel/rcu/update.c | 37 +++++++++++++++++++++++++++---------- 3 files changed, 61 insertions(+), 14 deletions(-)
include/linux/rcupdate.h +31 -4
@@ -226,6 +226,37 @@ struct rcu_synchronize { };void wakeme_after_rcu (struct rcu_head *head); +void __wait_rcu_gp (bool checktiny,int n,call_rcu_func_t *crcu_array, +struct rcu_synchronize *rs_array); + +#define _wait_rcu_gp (checktiny, ...) \ +do { \ + call_rcu_func_t __crcu_array[] = { __VA_ARGS__ }; \ + const int __n = ARRAY_SIZE(__crcu_array); \ + struct rcu_synchronize __rs_array[__n]; \ + \ + __wait_rcu_gp(checktiny, __n, __crcu_array, __rs_array); \ +} while (0) + +#define wait_rcu_gp (...) _wait_rcu_gp(false, __VA_ARGS__) + +/** +* synchronize_rcu_mult - Wait concurrently for multiple grace periods +* @...: List of call_rcu() functions for the flavors to wait on. +* +* This macro waits concurrently for multiple flavors of RCU grace periods. +* For example, synchronize_rcu_mult(call_rcu, call_rcu_bh) would wait +* on concurrent RCU and RCU-bh grace periods. Waiting on a give SRCU +* domain requires you to write a wrapper function for that SRCU domain's +* call_srcu() function, supplying the corresponding srcu_struct. +* +* If Tiny RCU, tell _wait_rcu_gp() not to bother waiting for RCU +* or RCU-bh, given that anywhere synchronize_rcu_mult() can be called +* is automatically a grace period. +*/ +#define synchronize_rcu_mult (...) \ + _wait_rcu_gp(IS_ENABLED(CONFIG_TINY_RCU), __VA_ARGS__) +/** * call_rcu_tasks() - Queue an RCU for invocation task-based grace period * @head: structure to be used for queueing the RCU updates.
@@ -392,10 +423,6 @@ bool __rcu_is_watching(void);* TREE_RCU and rcu_barrier_() primitives in TINY_RCU. */ -typedef void call_rcu_func_t (struct rcu_head *head, -void (*func)(struct rcu_head *head)); -void wait_rcu_gp (call_rcu_func_t crf); -#if defined(CONFIG_TREE_RCU ) || defined(CONFIG_PREEMPT_RCU )#include <linux/rcutree.h> #elif defined(CONFIG_TINY_RCU )
include/linux/types.h +3 -0
@@ -212,6 +212,9 @@ struct callback_head { };#define rcu_head callback_head +typedef void (*rcu_callback_t )(struct rcu_head *head); +typedef void (*call_rcu_func_t )(struct rcu_head *head,rcu_callback_t func); +/* clocksource cycle base type */ typedef u64 cycle_t ;
kernel/rcu/update.c +27 -10
@@ -318,20 +318,37 @@ void wakeme_after_rcu(struct rcu_head *head) rcu = container_of(head, struct rcu_synchronize, head);complete (&rcu->completion); } +EXPORT_SYMBOL_GPL (wakeme_after_rcu); -void wait_rcu_gp (call_rcu_func_t crf) +void __wait_rcu_gp (bool checktiny,int n,call_rcu_func_t *crcu_array, +struct rcu_synchronize *rs_array) { -struct rcu_synchronize rcu; +int i; -init_rcu_head_on_stack (&rcu.head); -init_completion (&rcu.completion); -/* Will wake me after RCU finished. */ -crf (&rcu.head, wakeme_after_rcu); -/* Wait for it. */ -wait_for_completion (&rcu.completion); -destroy_rcu_head_on_stack (&rcu.head); +/* Initialize and register callbacks for each flavor specified. */ +for (i =0 ; i < n; i++) { +if (checktiny && + (crcu_array[i] == call_rcu || + crcu_array[i] == call_rcu_bh)) { +might_sleep (); +continue ; + } +init_rcu_head_on_stack (&rs_array[i].head); +init_completion (&rs_array[i].completion); + (crcu_array[i])(&rs_array[i].head, wakeme_after_rcu); + } + +/* Wait for all callbacks to be invoked. */ +for (i =0 ; i < n; i++) { +if (checktiny && + (crcu_array[i] == call_rcu || + crcu_array[i] == call_rcu_bh)) +continue ; +wait_for_completion (&rs_array[i].completion); +destroy_rcu_head_on_stack (&rs_array[i].head); + } } -EXPORT_SYMBOL_GPL (wait_rcu_gp); +EXPORT_SYMBOL_GPL (__wait_rcu_gp);#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD void init_rcu_head (struct rcu_head *head)
Signature · 1 line
1.8.1.5
PATCH 9/16 cpu: Wait for RCU grace periods concurrently
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
In kernels built with CONFIG_PREEMPT, _cpu_down() waits for RCU and RCU-sched grace periods back-to-back, incurring quite a bit more latency than required. This commit therefore uses the new synchronize_rcu_mult() to allow waiting for both grace periods concurrently.
--- kernel/cpu.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
kernel/cpu.c +5 -5
@@ -380,14 +380,14 @@ static int __ref _cpu_down(unsigned int cpu, int tasks_frozen)* will observe it. * * For CONFIG_PREEMPT we have preemptible RCU and its sync_rcu() might -* not imply sync_sched(), so explicitly call both. +* not imply sync_sched(), so wait for both. * * Do sync before park smpboot threads to take care the rcu boost case. */ -#ifdef CONFIG_PREEMPT -synchronize_sched (); -#endif -synchronize_rcu (); +if (IS_ENABLED (CONFIG_PREEMPT )) +synchronize_rcu_mult (call_rcu, call_rcu_sched); +else +synchronize_rcu ();smpboot_park_threads (cpu);
Signature · 1 line
1.8.1.5
PATCH 10/16 rcu: Make rcu_is_watching() really notrace
In reply to Paul E. McKenneyFrom: Alexei Starovoitov <[email protected]>
Although rcu_is_watching() is marked notrace, it invokes preempt_disable() and preempt_enable(), both of which can be traced. This defeats the purpose of the notrace on rcu_is_watching(), so this commit substitutes preempt_disable_notrace() and preempt_enable_notrace().
--- kernel/rcu/tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/rcu/tree.c +2 -2
@@ -978,9 +978,9 @@ bool notrace rcu_is_watching(void) {bool ret; -preempt_disable (); +preempt_disable_notrace (); ret =__rcu_is_watching (); -preempt_enable (); +preempt_enable_notrace ();return ret; }EXPORT_SYMBOL_GPL (rcu_is_watching);
Signature · 1 line
1.8.1.5
PATCH 11/16 rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
This commit renames rcu_lockdep_assert() to RCU_LOCKDEP_WARN() for consistency with the WARN() series of macros. This also requires inverting the sense of the conditional, which this commit also does.
--- Documentation/RCU/whatisRCU.txt | 2 +- arch/x86/kernel/cpu/mcheck/mce.c | 6 ++-- arch/x86/kernel/traps.c | 2 +- drivers/base/power/opp.c | 4 +-- include/linux/fdtable.h | 4 +-- include/linux/rcupdate.h | 63 ++++++++++++++++++++++++++-------------- kernel/cgroup.c | 4 +-- kernel/pid.c | 5 ++-- kernel/rcu/srcu.c | 10 +++---- kernel/rcu/tiny.c | 8 ++--- kernel/rcu/tree.c | 28 +++++++++--------- kernel/rcu/tree_plugin.h | 8 ++--- kernel/rcu/update.c | 4 +-- kernel/sched/core.c | 8 ++--- kernel/workqueue.c | 20 ++++++------- security/device_cgroup.c | 6 ++-- 16 files changed, 101 insertions(+), 81 deletions(-)
Documentation/RCU/whatisRCU.txt +1 -1
@@ -883,7 +883,7 @@ All: lockdep-checked RCU-protected pointer access rcu_access_pointer rcu_dereference_raw - rcu_lockdep_assert + RCU_LOCKDEP_WARN rcu_sleep_check RCU_NONIDLE
arch/x86/kernel/cpu/mcheck/mce.c +3 -3
@@ -54,9 +54,9 @@ static DEFINE_MUTEX(mce_chrdev_read_mutex);#define rcu_dereference_check_mce (p) \ ({ \ - rcu_lockdep_assert(rcu_read_lock_sched_held() || \ - lockdep_is_held(&mce_chrdev_read_mutex), \ - "suspicious rcu_dereference_check_mce() usage"); \ + RCU_LOCKDEP_WARN(!rcu_read_lock_sched_held() && \ + !lockdep_is_held(&mce_chrdev_read_mutex), \ + "suspicious rcu_dereference_check_mce() usage"); \ smp_load_acquire(&(p)); \ })
arch/x86/kernel/traps.c +1 -1
@@ -136,7 +136,7 @@ enum ctx_state ist_enter(struct pt_regs *regs)preempt_count_add (HARDIRQ_OFFSET );/* This code is a bit fragile. Test it. */ -rcu_lockdep_assert (rcu_is_watching (),"ist_enter didn't work" ); +RCU_LOCKDEP_WARN (!rcu_is_watching (),"ist_enter didn't work" );return prev_state; }
drivers/base/power/opp.c +2 -2
@@ -110,8 +110,8 @@ static DEFINE_MUTEX(dev_opp_list_lock);#define opp_rcu_lockdep_assert () \ do { \ - rcu_lockdep_assert(rcu_read_lock_held() || \ - lockdep_is_held(&dev_opp_list_lock), \ + RCU_LOCKDEP_WARN(!rcu_read_lock_held() && \ + !lockdep_is_held(&dev_opp_list_lock), \ "Missing rcu_read_lock() or " \ "dev_opp_list_lock protection"); \ } while (0)
include/linux/fdtable.h +2 -2
@@ -86,8 +86,8 @@ static inline struct file *__fcheck_files(struct files_struct *files, unsigned istatic inline struct file *fcheck_files (struct files_struct *files,unsigned int fd) { -rcu_lockdep_assert (rcu_read_lock_held () || -lockdep_is_held (&files->file_lock), +RCU_LOCKDEP_WARN (!rcu_read_lock_held () && + !lockdep_is_held (&files->file_lock),"suspicious rcu_dereference_check() usage" );return __fcheck_files (files, fd); }
include/linux/rcupdate.h +42 -21
141 lines not on this page · raw message
kernel/cgroup.c +2 -2
@@ -107,8 +107,8 @@ static DEFINE_SPINLOCK(release_agent_path_lock);struct percpu_rw_semaphore cgroup_threadgroup_rwsem;#define cgroup_assert_mutex_or_rcu_locked () \ - rcu_lockdep_assert(rcu_read_lock_held() || \ - lockdep_is_held(&cgroup_mutex), \ + RCU_LOCKDEP_WARN(!rcu_read_lock_held() && \ + !lockdep_is_held(&cgroup_mutex), \ "cgroup_mutex or RCU read lock required");/*
kernel/pid.c +2 -3
@@ -451,9 +451,8 @@ EXPORT_SYMBOL(pid_task);*/ struct task_struct *find_task_by_pid_ns (pid_t nr,struct pid_namespace *ns) { -rcu_lockdep_assert (rcu_read_lock_held (), -"find_task_by_pid_ns() needs rcu_read_lock()" -" protection" ); +RCU_LOCKDEP_WARN (!rcu_read_lock_held (), +"find_task_by_pid_ns() needs rcu_read_lock() protection" );return pid_task (find_pid_ns (nr, ns),PIDTYPE_PID ); }
kernel/rcu/srcu.c +5 -5
@@ -415,11 +415,11 @@ static void __synchronize_srcu(struct srcu_struct *sp, int trycount)struct rcu_head *head = &rcu.head;bool done = false; -rcu_lockdep_assert (!lock_is_held (&sp->dep_map) && - !lock_is_held (&rcu_bh_lock_map) && - !lock_is_held (&rcu_lock_map) && - !lock_is_held (&rcu_sched_lock_map), -"Illegal synchronize_srcu() in same-type SRCU (or RCU) read-side critical section" ); +RCU_LOCKDEP_WARN (lock_is_held (&sp->dep_map) || +lock_is_held (&rcu_bh_lock_map) || +lock_is_held (&rcu_lock_map) || +lock_is_held (&rcu_sched_lock_map), +"Illegal synchronize_srcu() in same-type SRCU (or in RCU) read-side critical section" );might_sleep ();init_completion (&rcu.completion);
kernel/rcu/tiny.c +4 -4
@@ -191,10 +191,10 @@ static void rcu_process_callbacks(struct softirq_action *unused)*/ void synchronize_sched (void ) { -rcu_lockdep_assert (!lock_is_held (&rcu_bh_lock_map) && - !lock_is_held (&rcu_lock_map) && - !lock_is_held (&rcu_sched_lock_map), -"Illegal synchronize_sched() in RCU read-side critical section" ); +RCU_LOCKDEP_WARN (lock_is_held (&rcu_bh_lock_map) || +lock_is_held (&rcu_lock_map) || +lock_is_held (&rcu_sched_lock_map), +"Illegal synchronize_sched() in RCU read-side critical section" );cond_resched (); }EXPORT_SYMBOL_GPL (synchronize_sched);
kernel/rcu/tree.c +14 -14
@@ -649,12 +649,12 @@ static void rcu_eqs_enter_common(long long oldval, bool user)* It is illegal to enter an extended quiescent state while * in an RCU read-side critical section. */ -rcu_lockdep_assert (!lock_is_held (&rcu_lock_map), -"Illegal idle entry in RCU read-side critical section." ); -rcu_lockdep_assert (!lock_is_held (&rcu_bh_lock_map), -"Illegal idle entry in RCU-bh read-side critical section." ); -rcu_lockdep_assert (!lock_is_held (&rcu_sched_lock_map), -"Illegal idle entry in RCU-sched read-side critical section." ); +RCU_LOCKDEP_WARN (lock_is_held (&rcu_lock_map), +"Illegal idle entry in RCU read-side critical section." ); +RCU_LOCKDEP_WARN (lock_is_held (&rcu_bh_lock_map), +"Illegal idle entry in RCU-bh read-side critical section." ); +RCU_LOCKDEP_WARN (lock_is_held (&rcu_sched_lock_map), +"Illegal idle entry in RCU-sched read-side critical section." ); }/*
@@ -3161,10 +3161,10 @@ static inline int rcu_blocking_is_gp(void)*/ void synchronize_sched (void ) { -rcu_lockdep_assert (!lock_is_held (&rcu_bh_lock_map) && - !lock_is_held (&rcu_lock_map) && - !lock_is_held (&rcu_sched_lock_map), -"Illegal synchronize_sched() in RCU-sched read-side critical section" ); +RCU_LOCKDEP_WARN (lock_is_held (&rcu_bh_lock_map) || +lock_is_held (&rcu_lock_map) || +lock_is_held (&rcu_sched_lock_map), +"Illegal synchronize_sched() in RCU-sched read-side critical section" );if (rcu_blocking_is_gp ())return ;if (rcu_gp_is_expedited ())
@@ -3188,10 +3188,10 @@ EXPORT_SYMBOL_GPL(synchronize_sched);*/ void synchronize_rcu_bh (void ) { -rcu_lockdep_assert (!lock_is_held (&rcu_bh_lock_map) && - !lock_is_held (&rcu_lock_map) && - !lock_is_held (&rcu_sched_lock_map), -"Illegal synchronize_rcu_bh() in RCU-bh read-side critical section" ); +RCU_LOCKDEP_WARN (lock_is_held (&rcu_bh_lock_map) || +lock_is_held (&rcu_lock_map) || +lock_is_held (&rcu_sched_lock_map), +"Illegal synchronize_rcu_bh() in RCU-bh read-side critical section" );if (rcu_blocking_is_gp ())return ;if (rcu_gp_is_expedited ())
kernel/rcu/tree_plugin.h +4 -4
@@ -538,10 +538,10 @@ EXPORT_SYMBOL_GPL(call_rcu);*/ void synchronize_rcu (void ) { -rcu_lockdep_assert (!lock_is_held (&rcu_bh_lock_map) && - !lock_is_held (&rcu_lock_map) && - !lock_is_held (&rcu_sched_lock_map), -"Illegal synchronize_rcu() in RCU read-side critical section" ); +RCU_LOCKDEP_WARN (lock_is_held (&rcu_bh_lock_map) || +lock_is_held (&rcu_lock_map) || +lock_is_held (&rcu_sched_lock_map), +"Illegal synchronize_rcu() in RCU read-side critical section" );if (!rcu_scheduler_active)return ;if (rcu_gp_is_expedited ())
kernel/rcu/update.c +2 -2
@@ -589,8 +589,8 @@ EXPORT_SYMBOL_GPL(call_rcu_tasks);void synchronize_rcu_tasks (void ) {/* Complain if the scheduler has not started. */ -rcu_lockdep_assert (!rcu_scheduler_active, -"synchronize_rcu_tasks called too soon" ); +RCU_LOCKDEP_WARN (rcu_scheduler_active, +"synchronize_rcu_tasks called too soon" );/* Wait for the grace period. */ wait_rcu_gp (call_rcu_tasks);
kernel/sched/core.c +4 -4
@@ -2200,8 +2200,8 @@ unsigned long to_ratio(u64 period, u64 runtime)#ifdef CONFIG_SMP inline struct dl_bw *dl_bw_of (int i) { -rcu_lockdep_assert (rcu_read_lock_sched_held (), -"sched RCU must be held" ); +RCU_LOCKDEP_WARN (!rcu_read_lock_sched_held (), +"sched RCU must be held" );return &cpu_rq (i)->rd->dl_bw; }
@@ -2210,8 +2210,8 @@ static inline int dl_bw_cpus(int i)struct root_domain *rd =cpu_rq (i)->rd;int cpus =0 ; -rcu_lockdep_assert (rcu_read_lock_sched_held (), -"sched RCU must be held" ); +RCU_LOCKDEP_WARN (!rcu_read_lock_sched_held (), +"sched RCU must be held" );for_each_cpu_and (i, rd->span, cpu_active_mask) cpus++;
kernel/workqueue.c +10 -10
@@ -338,20 +338,20 @@ static void workqueue_sysfs_unregister(struct workqueue_struct *wq);#include <trace/events/workqueue.h> #define assert_rcu_or_pool_mutex () \ - rcu_lockdep_assert(rcu_read_lock_sched_held() || \ - lockdep_is_held(&wq_pool_mutex), \ - "sched RCU or wq_pool_mutex should be held") + RCU_LOCKDEP_WARN(!rcu_read_lock_sched_held() && \ + !lockdep_is_held(&wq_pool_mutex), \ + "sched RCU or wq_pool_mutex should be held")#define assert_rcu_or_wq_mutex (wq) \ - rcu_lockdep_assert(rcu_read_lock_sched_held() || \ - lockdep_is_held(&wq->mutex), \ - "sched RCU or wq->mutex should be held") + RCU_LOCKDEP_WARN(!rcu_read_lock_sched_held() && \ + !lockdep_is_held(&wq->mutex), \ + "sched RCU or wq->mutex should be held")#define assert_rcu_or_wq_mutex_or_pool_mutex (wq) \ - rcu_lockdep_assert(rcu_read_lock_sched_held() || \ - lockdep_is_held(&wq->mutex) || \ - lockdep_is_held(&wq_pool_mutex), \ - "sched RCU, wq->mutex or wq_pool_mutex should be held") + RCU_LOCKDEP_WARN(!rcu_read_lock_sched_held() && \ + !lockdep_is_held(&wq->mutex) && \ + !lockdep_is_held(&wq_pool_mutex), \ + "sched RCU, wq->mutex or wq_pool_mutex should be held")#define for_each_cpu_worker_pool (pool, cpu) \ for ((pool) = &per_cpu(cpu_worker_pools, cpu)[0]; \
security/device_cgroup.c +3 -3
@@ -400,9 +400,9 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup, {bool match = false; -rcu_lockdep_assert (rcu_read_lock_held () || -lockdep_is_held (&devcgroup_mutex), -"device_cgroup:verify_new_ex called without proper synchronization" ); +RCU_LOCKDEP_WARN (!rcu_read_lock_held () && +lockdep_is_held (&devcgroup_mutex), +"device_cgroup:verify_new_ex called without proper synchronization" );if (dev_cgroup->behavior ==DEVCG_DEFAULT_ALLOW ) {if (behavior ==DEVCG_DEFAULT_ALLOW ) {
Signature · 1 line
1.8.1.5
PATCH 12/16 rcu: Fix backwards RCU_LOCKDEP_WARN() in synchronize_rcu_tasks()
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
The RCU_LOCKDEP_WARN() in synchronize_rcu_tasks() triggers if the scheduler is active, which is backwards. This commit therefore negates the test.
--- kernel/rcu/update.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/rcu/update.c +1 -1
@@ -589,7 +589,7 @@ EXPORT_SYMBOL_GPL(call_rcu_tasks);void synchronize_rcu_tasks (void ) {/* Complain if the scheduler has not started. */ -RCU_LOCKDEP_WARN (rcu_scheduler_active, +RCU_LOCKDEP_WARN (!rcu_scheduler_active,"synchronize_rcu_tasks called too soon" );/* Wait for the grace period. */
Signature · 1 line
1.8.1.5
PATCH 13/16 rcu: Clarify CONFIG_RCU_EQS_DEBUG help text
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
--- lib/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
lib/Kconfig.debug +1 -1
@@ -1379,7 +1379,7 @@ config RCU_TRACE Say N if you are unsure. config RCU_EQS_DEBUG - bool "Use this when adding any sort of NO_HZ support to your arch" + bool "Provide debugging asserts for adding NO_HZ support to an arch" depends on DEBUG_KERNEL help This option provides consistency checks in RCU's handling of
Signature · 1 line
1.8.1.5
PATCH 14/16 rcu: update MAINTAINERS entry
In reply to Paul E. McKenneyFrom: Lai Jiangshan <[email protected]>
This commit updates Lai Jiangshan's email address because the old [email protected] address will expire after July 10, 2015.
--- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
MAINTAINERS +3 -3
@@ -8445,7 +8445,7 @@ M: "Paul E. McKenney" <[email protected]> M: Josh Triplett <[email protected]> R: Steven Rostedt <[email protected]> R: Mathieu Desnoyers <[email protected]> -R: Lai Jiangshan <[email protected]> +R: Lai Jiangshan <[email protected]> L: [email protected] S: Supported T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
@@ -8472,7 +8472,7 @@ M: "Paul E. McKenney" <[email protected]> M: Josh Triplett <[email protected]> R: Steven Rostedt <[email protected]> R: Mathieu Desnoyers <[email protected]> -R: Lai Jiangshan <[email protected]> +R: Lai Jiangshan <[email protected]> L: [email protected] W: http://www.rdrop.com/users/paulmck/RCU/ S: Supported
@@ -9340,7 +9340,7 @@ F: include/linux/sl?b*.h F: mm/sl?b* SLEEPABLE READ-COPY UPDATE (SRCU) -M: Lai Jiangshan <[email protected]> +M: Lai Jiangshan <[email protected]> M: "Paul E. McKenney" <[email protected]> M: Josh Triplett <[email protected]> R: Steven Rostedt <[email protected]>
Signature · 1 line
1.8.1.5
PATCH 15/16 scripts: Make checkpatch.pl warn on expedited RCU grace periods
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
The synchronize_rcu_expedited() and synchronize_sched_expedited() expedited-grace-period primitives induce OS jitter, which can degrade real-time response. This commit therefore adds a checkpatch.pl warning on any patch adding them.
Note that this patch does not warn on synchronize_srcu_expedited() because it does not induce OS jitter, courtesy of its otherwise much-maligned read-side memory barriers.
--- scripts/checkpatch.pl | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
scripts/checkpatch.pl +19 -0
@@ -5011,6 +5011,7 @@ sub process { "memory barrier without comment\n" . $herecurr); } } + # check for waitqueue_active without a comment. if ($line =~ /\bwaitqueue_active\s*\(/) { if (!ctx_has_comment($first_line, $linenr)) {
@@ -5018,6 +5019,24 @@ sub process { "waitqueue_active without comment\n" . $herecurr); } } + +# Check for expedited grace periods that interrupt non-idle non-nohz +# online CPUs. These expedited can therefore degrade real-time response +# if used carelessly, and should be avoided where not absolutely +# needed. It is always OK to use synchronize_rcu_expedited() and +# synchronize_sched_expedited() at boot time (before real-time applications +# start) and in error situations where real-time response is compromised in +# any case. Note that synchronize_srcu_expedited() does -not- interrupt +# other CPUs, so don't warn on uses of synchronize_srcu_expedited(). +# Of course, nothing comes for free, and srcu_read_lock() and +# srcu_read_unlock() do contain full memory barriers in payment for +# synchronize_srcu_expedited() non-interruption properties. + if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) { + WARN("EXPEDITED_RCU_GRACE_PERIOD", + "expedited RCU grace periods should be avoided in cases where they can degrade real-time response\n" . $herecurr); + + } + # check of hardware specific defines if ($line =~ m@^.\s*\#\s*if.*\b(__i386__|__powerpc64__|__sun__|__s390x__)\b@ && $realfile !~ m@include/asm-@) { CHK("ARCH_DEFINES",
Signature · 1 line
1.8.1.5
Joe Perches
maintainerRe: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
Quoted 4 lines · Paul E. McKenney
The
synchronize_rcu_expedited()andsynchronize_sched_expedited()expedited-grace-period primitives induce OS jitter, which can degrade real-time response. This commit therefore adds a checkpatch.pl warning on any patch adding them.
[]
scripts/checkpatch.pl
Quoted 1 line
scripts/checkpatch.pl +0
-0
[]
scripts/checkpatch.pl sub process { · line 5034
Quoted 12 lines
scripts/checkpatch.pl +12
-0+# Check for expedited grace periods that interrupt non-idle non-nohz +# online CPUs. These expedited can therefore degrade real-time response +# if used carelessly, and should be avoided where not absolutely +# needed. It is always OK to use synchronize_rcu_expedited() and +# synchronize_sched_expedited() at boot time (before real-time applications +# start) and in error situations where real-time response is compromised in +# any case. Note that synchronize_srcu_expedited() does -not- interrupt +# other CPUs, so don't warn on uses of synchronize_srcu_expedited(). +# Of course, nothing comes for free, and srcu_read_lock() and +# srcu_read_unlock() do contain full memory barriers in payment for +# synchronize_srcu_expedited() non-interruption properties. + if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) {
It'd be faster perl without capture groups:
if ($line =~ /\b(?:synchronize_(?:rcu|sched)_expedited)\s*\(/) {scripts/checkpatch.pl sub process { · line 5036
Quoted 2 lines
scripts/checkpatch.pl +2
-0+ WARN("EXPEDITED_RCU_GRACE_PERIOD", + "expedited RCU grace periods should be avoided in cases where they can degrade real-time response\n" . $herecurr);
"in cases" is rather redundant.
Re: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
Quoted 23 lines · Joe Perches
Quoted 4 lines · Paul E. McKenney
The
synchronize_rcu_expedited()andsynchronize_sched_expedited()expedited-grace-period primitives induce OS jitter, which can degrade real-time response. This commit therefore adds a checkpatch.pl warning on any patch adding them.[]
scripts/checkpatch.pl
Quoted 1 line
scripts/checkpatch.pl +0
-0[]
scripts/checkpatch.pl sub process { · line 5034
Quoted 12 lines
scripts/checkpatch.pl +12
-0+# Check for expedited grace periods that interrupt non-idle non-nohz +# online CPUs. These expedited can therefore degrade real-time response +# if used carelessly, and should be avoided where not absolutely +# needed. It is always OK to use synchronize_rcu_expedited() and +# synchronize_sched_expedited() at boot time (before real-time applications +# start) and in error situations where real-time response is compromised in +# any case. Note that synchronize_srcu_expedited() does -not- interrupt +# other CPUs, so don't warn on uses of synchronize_srcu_expedited(). +# Of course, nothing comes for free, and srcu_read_lock() and +# srcu_read_unlock() do contain full memory barriers in payment for +# synchronize_srcu_expedited() non-interruption properties. + if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) {It'd be faster perl without capture groups:
Quoted 1 line
if ($line =~ /\b(?:synchronize_(?:rcu|sched)_expedited)\s*\(/) {Fair enough, but this pattern is used rather heavily in this script, and I don't trust my perl enough to want to create a new pattern.
I see a couple of possible ways forward:
1. I hand this patch off to you, and you update it as you deem fit.
2. I push the patch as is (after the fix below) and you update
checkpatch as a whole to use the more efficient code.
How would you like to proceed?
Quoted 4 lines
scripts/checkpatch.pl sub process { · line 5036
Quoted 2 lines
scripts/checkpatch.pl +2
-0+ WARN("EXPEDITED_RCU_GRACE_PERIOD", + "expedited RCU grace periods should be avoided in cases where they can degrade real-time response\n" . $herecurr);"in cases" is rather redundant.
I did make this change.
Thanx, Paul
Joe Perches
maintainerRe: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
Quoted 8 lines · Paul E. McKenney
Quoted 3 lines · Joe Perches
It'd be faster perl without capture groups:
if ($line =~ /\b(?:synchronize_(?:rcu|sched)_expedited)\s*\(/) {Fair enough, but this pattern is used rather heavily in this script, and I don't trust my perl enough to want to create a new pattern.
Quoted 8 lines
I see a couple of possible ways forward:
1. I hand this patch off to you, and you update it as you deem fit.
2. I push the patch as is (after the fix below) and you update
checkpatch as a whole to use the more efficient code.How would you like to proceed?
Push and fix would work fine.
Re: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
Quoted 11 lines · Joe Perches
Quoted 10 lines · Paul E. McKenney
Quoted 3 lines · Joe Perches
It'd be faster perl without capture groups:
if ($line =~ /\b(?:synchronize_(?:rcu|sched)_expedited)\s*\(/) {Fair enough, but this pattern is used rather heavily in this script, and I don't trust my perl enough to want to create a new pattern.
I see a couple of possible ways forward:
Quoted 8 lines
Quoted 6 lines
1. I hand this patch off to you, and you update it as you deem fit.
2. I push the patch as is (after the fix below) and you update
checkpatch as a whole to use the more efficient code.How would you like to proceed?
Push and fix would work fine.
Very good, will do!
Thanx, Paul
Steven Rostedt
reviewerRe: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
In reply to Joe PerchesQuoted 3 lines · On Fri, 17 Jul 2015 15:37:54 -0700 Joe Perches <[email protected]> wrote:
scripts/checkpatch.pl sub process { · line 5034
Quoted 1 line
scripts/checkpatch.pl +1
-0+ if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) {It'd be faster perl without capture groups:
Is checkpatch such a critical code path that we could possibly notice the difference in speed? Although the above may be few microseconds slower, to me, the above looks a hell of a lot more readable.
-- Steve
Joe Perches
maintainerRe: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
Quoted 10 lines · Steven Rostedt
Quoted 3 lines · On Fri, 17 Jul 2015 15:37:54 -0700 Joe Perches <[email protected]> wrote:
scripts/checkpatch.pl sub process { · line 5034
Quoted 1 line
scripts/checkpatch.pl +1
-0+ if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) {It'd be faster perl without capture groups:
Is checkpatch such a critical code path that we could possibly notice the difference in speed? Although the above may be few microseconds slower, to me, the above looks a hell of a lot more readable.
Regardless, it's not as capable as it wouldn't find any miswritten form like
synchronize_<foo>_expedited ( args... )
Steven Rostedt
reviewerRe: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
Quoted 8 lines · On Mon, 20 Jul 2015 18:06:19 -0700 Joe Perches <[email protected]> wrote:
Quoted 7 lines · Steven Rostedt
Quoted 3 lines · On Fri, 17 Jul 2015 15:37:54 -0700 Joe Perches <[email protected]> wrote:
scripts/checkpatch.pl sub process { · line 5034
Quoted 1 line
scripts/checkpatch.pl +1
-0+ if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) {It'd be faster perl without capture groups:
Quoted 8 lines
Quoted 3 lines
Is checkpatch such a critical code path that we could possibly notice the difference in speed? Although the above may be few microseconds slower, to me, the above looks a hell of a lot more readable.
Regardless, it's not as capable as it wouldn't find any miswritten form like
synchronize_<foo>_expedited ( args... )
Then that's a better rational than performance.
-- Steve
Joe Perches
maintainerRe: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
Quoted 9 lines · Steven Rostedt
Quoted 8 lines · On Mon, 20 Jul 2015 18:06:19 -0700 Joe Perches <[email protected]> wrote:
Quoted 7 lines · Steven Rostedt
Quoted 2 lines · On Fri, 17 Jul 2015 15:37:54 -0700 Joe Perches <[email protected]> wrote:
scripts/checkpatch.pl sub process { · line 5034
Quoted 1 line
scripts/checkpatch.pl +1
-0+ if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) {It'd be faster perl without capture groups:
Is checkpatch such a critical code path that we could possibly notice the difference in speed? Although the above may be few microseconds slower, to me, the above looks a hell of a lot more readable.
Not to me. Compact is generally more readable.
Quoted 6 lines
Quoted 4 lines
Regardless, it's not as capable as it wouldn't find any miswritten form like
synchronize_<foo>_expedited ( args... )
Then that's a better rational than performance.
Part and parcel.
Regardless, I'll send a patch once it's actually pushed.
Re: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
Quoted 16 lines · Joe Perches
Quoted 9 lines · Steven Rostedt
Quoted 8 lines · On Mon, 20 Jul 2015 18:06:19 -0700 Joe Perches <[email protected]> wrote:
Quoted 7 lines · Steven Rostedt
Quoted 2 lines · On Fri, 17 Jul 2015 15:37:54 -0700 Joe Perches <[email protected]> wrote:
scripts/checkpatch.pl sub process { · line 5034
Quoted 1 line
scripts/checkpatch.pl +1
-0+ if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) {It'd be faster perl without capture groups:
Is checkpatch such a critical code path that we could possibly notice the difference in speed? Although the above may be few microseconds slower, to me, the above looks a hell of a lot more readable.
Not to me. Compact is generally more readable.
Quoted 3 lines
Quoted 3 lines
Regardless, it's not as capable as it wouldn't find any miswritten form like
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
synchronize_<foo>_expedited ( args... )
Then that's a better rational than performance.
Part and parcel.
Regardless, I'll send a patch once it's actually pushed.
Current plan is to push it into the upcoming merge window.
Thanx, Paul
Re: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
In reply to Joe PerchesQuoted 8 lines · Joe Perches
Quoted 7 lines · Steven Rostedt
Quoted 3 lines · On Fri, 17 Jul 2015 15:37:54 -0700 Joe Perches <[email protected]> wrote:
Review
Quoted 1 line
(quoted diff) +1
-0+ if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) {It'd be faster perl without capture groups:
Quoted 8 lines
Quoted 3 lines
Is checkpatch such a critical code path that we could possibly notice the difference in speed? Although the above may be few microseconds slower, to me, the above looks a hell of a lot more readable.
Regardless, it's not as capable as it wouldn't find any miswritten form like
synchronize_<foo>_expedited ( args... )
Hmmm... My current patch doesn't complain about this:
------------------------------------------------------------------------
kernel/rcu/rcutorture.c +2 -0
@@ -492,6 +492,8 @@ static void srcu_read_delay(struct torture_random_state *rrsp)const long uspertick =1000000 /HZ ;const long longdelay =10 ; +synchronize_srcu_expedited (srcu_ctlp); +/* We want there to be long-running readers, but not all the time. */ delay = torture_random(rrsp) %
------------------------------------------------------------------------
But it does correctly complain when I add synchronize_rcu_expedited() or synchronize_sched_expedited().
So what am I missing here?
Thanx, Paul
Joe Perches
maintainerRe: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
Quoted 38 lines · Paul E. McKenney
Quoted 8 lines · Joe Perches
Quoted 7 lines · Steven Rostedt
Quoted 3 lines · On Fri, 17 Jul 2015 15:37:54 -0700 Joe Perches <[email protected]> wrote:
Review
Quoted 1 line
(quoted diff) +1
-0+ if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) {It'd be faster perl without capture groups:
Quoted 8 lines
Quoted 3 lines
Is checkpatch such a critical code path that we could possibly notice the difference in speed? Although the above may be few microseconds slower, to me, the above looks a hell of a lot more readable.
Regardless, it's not as capable as it wouldn't find any miswritten form like
synchronize_<foo>_expedited ( args... )
Hmmm... My current patch doesn't complain about this:
------------------------------------------------------------------------
kernel/rcu/rcutorture.c +2
-1@@ -492,6 +492,8 @@ static void srcu_read_delay(struct torture_random_state *rrsp)const long uspertick =1000000 /HZ ;const long longdelay =10 ; +synchronize_srcu_expedited (srcu_ctlp); +/* We want there to be long-running readers, but not all the time. */ delay = torture_random(rrsp) % ------------------------------------------------------------------------
Quoted 4 lines
But it does correctly complain when I add
synchronize_rcu_expedited()orsynchronize_sched_expedited().So what am I missing here?
A space between the function name and the open parenthesis
Re: [PATCH tip/core/rcu 15/16] scripts: Make checkpatch.pl warn on expedited RCU grace periods
Quoted 37 lines · Joe Perches
Quoted 36 lines · Paul E. McKenney
Quoted 8 lines · Joe Perches
Quoted 7 lines · Steven Rostedt
Quoted 3 lines · On Fri, 17 Jul 2015 15:37:54 -0700 Joe Perches <[email protected]> wrote:
Review
Quoted 1 line
(quoted diff) +1
-0+ if ($line =~ /\b(synchronize_rcu_expedited|synchronize_sched_expedited)\(/) {It'd be faster perl without capture groups:
Quoted 8 lines
Quoted 3 lines
Is checkpatch such a critical code path that we could possibly notice the difference in speed? Although the above may be few microseconds slower, to me, the above looks a hell of a lot more readable.
Regardless, it's not as capable as it wouldn't find any miswritten form like
synchronize_<foo>_expedited ( args... )
Hmmm... My current patch doesn't complain about this:
------------------------------------------------------------------------
kernel/rcu/rcutorture.c +2
-0@@ -492,6 +492,8 @@ static void srcu_read_delay(struct torture_random_state *rrsp)const long uspertick =1000000 /HZ ;const long longdelay =10 ; +synchronize_srcu_expedited (srcu_ctlp); +/* We want there to be long-running readers, but not all the time. */ delay = torture_random(rrsp) %
Quoted 8 lines
Quoted 6 lines
------------------------------------------------------------------------
But it does correctly complain when I add
synchronize_rcu_expedited()orsynchronize_sched_expedited().So what am I missing here?
A space between the function name and the open parenthesis
Got it, thank you!
Thanx, Paul
PATCH 16/16 rcu: Don't disable CPU hotplug during OOM notifiers
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
RCU's rcu_oom_notify() disables CPU hotplug in order to stabilize the list of online CPUs, which it traverses. However, this is completely pointless because smp_call_function_single() will quietly fail if invoked on an offline CPU. Because the count of requests is incremented in the rcu_oom_notify_cpu() function that is remotely invoked, everything works nicely even in the face of concurrent CPU-hotplug operations.
Furthermore, in recent kernels, invoking get_online_cpus() from an OOM notifier can result in deadlock. This commit therefore removes the call to get_online_cpus() and put_online_cpus() from rcu_oom_notify().
--- kernel/rcu/tree_plugin.h | 2 -- 1 file changed, 2 deletions(-)
kernel/rcu/tree_plugin.h +0 -2
@@ -1679,12 +1679,10 @@ static int rcu_oom_notify(struct notifier_block *self,*/ atomic_set (&oom_callback_count,1 ); -get_online_cpus ();for_each_online_cpu (cpu) {smp_call_function_single (cpu, rcu_oom_notify_cpu,NULL ,1 );cond_resched_rcu_qs (); } -put_online_cpus ();/* Unconditionally decrement: no need to wake ourselves up. */ atomic_dec (&oom_callback_count);
Signature · 1 line
1.8.1.5