- 27 May, 2015 40 commits
-
-
Paul E. McKenney authored
Merge branches 'array.2015.05.27a', 'doc.2015.05.27a', 'fixes.2015.05.27a', 'hotplug.2015.05.27a', 'init.2015.05.27a', 'tiny.2015.05.27a' and 'torture.2015.05.27a' into HEAD array.2015.05.27a: Remove all uses of RCU-protected array indexes. doc.2015.05.27a: Docuemntation updates. fixes.2015.05.27a: Miscellaneous fixes. hotplug.2015.05.27a: CPU-hotplug updates. init.2015.05.27a: Initialization/Kconfig updates. tiny.2015.05.27a: Updates to Tiny RCU. torture.2015.05.27a: Torture-testing updates.
-
Paul E. McKenney authored
Although it is currently possible to run the same test in parallel, '--config "TINY01 TINY01 TINY01"' can get a bit verbose, especially if you want to run 48 instances of TINY01 in parallel. This commit therefore allows prefixing the Kconfig fragment with a repeat count, for example, '--config "48*TINY01"' to run 48 instances in parallel. At least assuming that you have 48 CPUs and also gave '--cpus 48'. Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org>
-
Paul E. McKenney authored
The current rcutorture scripting fails to dump out errors from "make oldconfig", so this commit addresses this issue. Signed-off-by:
-
Paul E. McKenney authored
This commit updates TREE_RCU-kconfig.txt to reflect changes in RCU's Kconfig setup. This commit also updates rcutorture's Kconfig fragments to account for Kconfig parameters that are now driven directly off of other Kconfig parameters. The #CHECK# prefix tells the rcutorture scripts to take no action to try to set the Kconfig parameter, but to check that it does in fact get set. This is useful for verifying that Kconfig parameters that are supposed to be automatically set do in fact get set to the required values. Reported-by:
Pranith Kumar <bobby.prani@gmail.com> Signed-off-by:
-
Paul E. McKenney authored
This commit causes the rcutorture scripts to force RCU_EXPERT so that these scripts can cause rcutorture to torture RCU in the various required configurations. However, SRCU-P, TASKS03, and TREE09 retain !RCU_EXPERT in order to ensure testing of the vanilla configuration. Signed-off-by:
-
Paul E. McKenney authored
This commit updates rcutortures configuration-fragment files to account for the move from the CONFIG_RCU_FANOUT_EXACT Kconfig parameter to the new rcutree.rcu_fanout_exact= boot parameter. Signed-off-by:
-
Paul E. McKenney authored
The TASKS01, TASKS02, and TASKS03 rcutorture config fragments currently set CONFIG_TASKS_RCU. However, now that the value of this Kconfig parameter is set via "select" statements, it is no longer necessary to set it explicitly. This commit therefore removes it from the Kconfig fragments. Signed-off-by:
-
Paul E. McKenney authored
The current rcutorture testing does not do any cleanup operations. This works because the srcu_struct is statically allocated, but it does represent a memory leak of the associated dynamically allocated ->per_cpu_ref per-CPU variables. However, rcutorture currently uses a statically allocated srcu_struct, which cannot legally be passed to cleanup_srcu_struct(). Therefore, this commit adds a second form of srcu (called srcud) that dynamically allocates and frees the associated per-CPU variables. This commit also adds a ->cleanup() member to rcu_torture_ops that is invoked at the end of the test, after ->cb_barriers(). This ->cleanup() pointer is NULL for all existing tests, and thus only used for scrud. Finally, the SRCU-P torture-test configuration selects scrud instead of srcu, with SRCU-N continuing to use srcu, thereby testing both static and dynamic srcu_struct structures. Reported-by:
"Ahmed, Iftekhar" <ahmedi@onid.oregonstate.edu> Signed-off-by:
-
Paul E. McKenney authored
The rcutorture.c file uses several explicit memory barriers that can easily be converted to smp_store_release() and smp_load_acquire(), which improves maintainability and also improves performance a bit. Signed-off-by:
-
Paul E. McKenney authored
The locktorture long delays are in milliseconds rather than microseconds, so this commit changes the name of the corresponding variable from longdelay_us to longdelay_ms. Reported-by:
Ben Goodwyn <bgoodwyn@softnas.com> Signed-off-by:
-
Paul E. McKenney authored
By default, with rcutorture.nreaders equal to -1, rcutorture provisions N-1 reader kthreads, where N is the number of CPUs. This avoids rcutorture-induced stalls, but also avoids heavier levels of torture. This commit therefore allows negative values of rcutorture.nreaders to specify larger numbers of reader kthreads, so that for example rcutorture.nreaders=-2 provisions N kthreads and rcutorture.nreaders=-5 provisions N+3 kthreads. Signed-off-by: -
Paul E. McKenney authored
TREE03 has been especially effective at finding bugs lately. This commit makes it even more effective by speeding up its CPU hotplug testing and increasing its NR_CPUs from 8 to 16. TREE08's NR_CPUS is decreased from 16 to 8 in order to maintain the same test duration. Signed-off-by:
-
Paul E. McKenney authored
Given that the combination of PREEMPT_RCU and HOTPLUG_CPU is producing the most bugs lately, this commit swaps the TREE03 and TREE04 rcu_node-tree geometries so that the test exercising PREEMPT_RCU and HOTPLUG_CPU has three-level rather than two-level rcu_node trees. Signed-off-by:
-
Alexey Kodanev authored
torture_rwlock_read_unlock_irq() must use read_unlock_irqrestore() instead of write_unlock_irqrestore(). Use read_unlock_irqrestore() instead of write_unlock_irqrestore(). Signed-off-by:
Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by:
-
Paul E. McKenney authored
If, at the time __rcu_process_callbacks() is invoked, there are callbacks in Tiny RCU's callback list, but none of them are ready to be invoked, the current list-management code will knit the non-ready callbacks out of the list. This can result in hangs and possibly worse. This commit therefore inserts a check for there being no callbacks that can be invoked immediately. This bug is unlikely to occur -- you have to get a new callback between the time rcu_sched_qs() or rcu_bh_qs() was called, but before we get to __rcu_process_callbacks(). It was detected by the addition of RCU-bh testing to rcutorture, which in turn was instigated by Iftekhar Ahmed's mutation testing. Although this bug was made much more likely by 915e8a4f (rcu: Remove fastpath from __rcu_process_callbacks()), this did not cause the bug, but rather made it much more probable. That said, it takes more than 40 hours of rcutorture testing, on average, for this bug to appear, so this fix cannot be considered an emergency. Signed-off-by:
-
Paul E. McKenney authored
Tiny RCU supports both RCU-sched and RCU-bh, but only RCU-sched is currently tested by the rcutorture scripts. This commit therefore changes the TINY02 configuration to test RCU-bh, with TINY01 continuing to test RCU-sched. This shortcoming of the current rcutorture tests was located by mutation testing by Iftekhar. The idea behind mutation testing is to automatically mutate the code under test. If a given mutant is not caught by testing, this is a hint that the testing might need to be improved, as was the case here. Note that this is only a hint because it is possible to mutate the code into something else that still works. For example, a mutation that removes (say) a WARN_ON() will not normally result in a test failure. This change resulted in the test failure caused by list mishandling, which is fixed by the next commit. Reported-by:
-
Paul E. McKenney authored
The Tiny RCU counterparts to rcu_idle_enter(), rcu_idle_exit(), rcu_irq_enter(), and rcu_irq_exit() are empty functions, but each has EXPORT_SYMBOL_GPL(), which needlessly consumes extra memory, especially in kernels built with module support. This commit therefore moves these functions to static inlines in rcutiny.h, removing the need for exports. This won't affect the size of the tiniest kernels, which are likely built without module support, but might help semi-tiny kernels that might include module support. Signed-off-by:
-
Paul E. McKenney authored
This commit applies some warning-omission micro-optimizations to RCU's various extended-quiescent-state functions, which are on the kernel/user hotpath for CONFIG_NO_HZ_FULL=y. Reported-by:
Rik van Riel <riel@redhat.com> Reported by: Mike Galbraith <umgwanakikbuti@gmail.com> Signed-off-by:
-
Pranith Kumar authored
The RCU implementation is chosen based on PREEMPT and SMP config options and is not really a user-selectable choice. This commit removes the menu entry, given that there is not much point in calling something a choice when there is in fact no choice.. The TINY_RCU, TREE_RCU, and PREEMPT_RCU Kconfig options continue to be selected based solely on the values of the PREEMPT and SMP options. Signed-off-by:
-
Paul E. McKenney authored
This commit updates the initialization of the kthread_prio boot parameter so that RCU will build even when CONFIG_RCU_KTHREAD_PRIO is undefined. The kthread_prio boot parameter is set to CONFIG_RCU_KTHREAD_PRIO if that is defined, otherwise to 1 if CONFIG_RCU_BOOST is defined and to zero otherwise. This commit then makes CONFIG_RCU_KTHREAD_PRIO depend on CONFIG_RCU_EXPERT, so that Kconfig users won't be asked about CONFIG_RCU_KTHREAD_PRIO unless they want to be. Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Reported-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Paul E. McKenney authored
This commit introduces an RCU_FANOUT_LEAF C-preprocessor macro so that RCU will build even when CONFIG_RCU_FANOUT_LEAF is undefined. The RCU_FANOUT_LEAF macro is set to the value of CONFIG_RCU_FANOUT_LEAF when defined, otherwise it is set to 32 for 32-bit systems and 64 for 64-bit systems. This commit then makes CONFIG_RCU_FANOUT_LEAF depend on CONFIG_RCU_EXPERT, so that Kconfig users won't be asked about CONFIG_RCU_FANOUT_LEAF unless they want to be. Reported-by:
-
Paul E. McKenney authored
This commit introduces an RCU_FANOUT C-preprocessor macro so that RCU will build even when CONFIG_RCU_FANOUT is undefined. The RCU_FANOUT macro is set to the value of CONFIG_RCU_FANOUT when defined, otherwise it is set to 32 for 32-bit systems and 64 for 64-bit systems. This commit then makes CONFIG_RCU_FANOUT depend on CONFIG_RCU_EXPERT, so that Kconfig users won't be asked about CONFIG_RCU_FANOUT unless they want to be. Reported-by:
-
Paul E. McKenney authored
RCU_FANOUT_LEAF's range and default values depend on the value of RCU_FANOUT, which at the time seemed like a cute way to save two lines of Kconfig code. However, adding a dependency from both of these Kconfig parameters on RCU_EXPERT requires that RCU_FANOUT_LEAF operate correctly even if RCU_FANOUT is undefined. This commit therefore allows RCU_FANOUT_LEAF to take on the full range of permitted values, even in cases where RCU_FANOUT is undefined. Signed-off-by:
-
Paul E. McKenney authored
This commit creates an RCU_EXPERT Kconfig and hides the independent boolean RCU-related user-visible Kconfig parameters behind it, namely RCU_FAST_NO_HZ and RCU_BOOST. This prevents Kconfig from asking about these parameters unless the user really wants to be asked. Reported-by:
-
Paul E. McKenney authored
The purpose of this commit is to make it easier to verify that RCU's combining tree is set up correctly, which is useful to have when making changes in how that tree is initialized. Signed-off-by:
-
Paul E. McKenney authored
The CONFIG_RCU_FANOUT_EXACT Kconfig parameter is used primarily (and perhaps only) by rcutorture to verify that RCU works correctly in specific rcu_node combining-tree configurations. It therefore does not make much sense have this as a question to people attempting to configure their kernels. So this commit creates an rcutree.rcu_fanout_exact= boot parameter that rcutorture can use, and eliminates the original CONFIG_RCU_FANOUT_EXACT Kconfig parameter. Reported-by:
-
Paul E. McKenney authored
Currently, Kconfig will ask the user whether RCU_USER_QS should be set. This is silly because Kconfig already has all the information that it needs to set this parameter. This commit therefore directly drives the value of RCU_USER_QS via NO_HZ_FULL's "select" statement. Reported-by:
Frederic Weisbecker <fweisbec@gmail.com>
-
Paul E. McKenney authored
Currently, Kconfig will ask the user whether TASKS_RCU should be set. This is silly because Kconfig already has all the information that it needs to set this parameter. This commit therefore directly drives the value of TASKS_RCU via "select" statements. Which means that as subsystems require TASKS_RCU, those subsystems will need to add "select" statements of their own. Reported-by:
-
Paul E. McKenney authored
Grace-period scans of the rcu_node combining tree normally proceed quite quickly, so that it is very difficult to reproduce races against them. This commit therefore allows grace-period pre-initialization and cleanup to be artificially slowed down, increasing race-reproduction probability. A pair of pairs of new Kconfig parameters are provided, RCU_TORTURE_TEST_SLOW_PREINIT to enable the slowing down of propagating CPU-hotplug changes up the combining tree along with RCU_TORTURE_TEST_SLOW_PREINIT_DELAY to specify the delay in jiffies, and RCU_TORTURE_TEST_SLOW_CLEANUP to enable the slowing down of the end-of-grace-period cleanup scan along with RCU_TORTURE_TEST_SLOW_CLEANUP_DELAY to specify the delay in jiffies. Boot-time parameters named rcutree.gp_preinit_delay and rcutree.gp_cleanup_delay allow these delays to be specified at boot time. Signed-off-by: -
Paul E. McKenney authored
Because gcc doesn't realize that rcu_num_lvls must be strictly greater than zero, some versions give a spurious warning about levelcnt[0] being uninitialized in rcu_init_one(). This commit updates the condition on the pre-existing panic() in order to educate gcc on this point. Signed-off-by: -
Paul E. McKenney authored
Currently, the larger the gp_init_delay boot parameter, the slower rcutorture will sequence through grace periods. This commit avoids this issue by decreasing the probability of slowing initialization of a given grace period as the degree of slowness increases. Signed-off-by: -
Paul Gortmaker authored
We removed __cpuinit support (leaving no-op stubs) quite some time ago. However a new instance was added in commit 00df35f9 ("cpu: Defer smpboot kthread unparking until CPU known to scheduler") Since we want to clobber the stubs soon, get this removed now. Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Paul E. McKenney authored
Commit 00df35f9 (cpu: Defer smpboot kthread unparking until CPU known to scheduler) put the online path's call to smpboot_unpark_threads() into a CPU-hotplug notifier. This commit places the offline-failure paths call into the same notifier for the sake of uniformity. Note that it is not currently possible to place the offline path's call to smpboot_park_threads() into an existing notifier because the CPU_DYING notifiers run in a restricted environment, and the CPU_UP_PREPARE notifiers run too soon. Signed-off-by:
-
Paul E. McKenney authored
The rcu_data structure's ->rcu_qs_ctr_snap field is initialized at CPU-online time from the current CPU's element of the per-CPU rcu_qs_ctr variable. Unfortunately, this is at CPU_UP_PREPARE time, so has nothing to do with the CPU being onlined. This commit therefore initializes this variable from the incoming CPU's element of rcu_qs_ctr. Signed-off-by: -
Paul E. McKenney authored
Because offline CPUs are propagated up the rcu_node tree's ->qsmaskinit bits just before each grace period starts, the ->qsmaskinit bit cannot be clear when the corresponding ->qsmask bit is set. Furthermore, this condition used to correspond to a CPU that was on its way offline, and making RCU's notion of an offline CPU more precise has eliminated this situation. This commit therefore removes the now-redundant offline check from force_qs_rnp(). Signed-off-by: -
Paul E. McKenney authored
Because force_qs_rnp() is invoked only from the force-quiescent-state code which runs only in the context of the grace-period kthread, a grace period must always be in progress throughout force_qs_rnp()'s execution. This commit therefore removes the rcu_gp_in_progress() check and the associated dead code. Signed-off-by: -
Paul E. McKenney authored
Tasks are no longer migrated away from a given rcu_node structure when all CPUs corresponding to that rcu_node structure have gone offline. This means that rcu_read_unlock_special() no longer needs to loop retrying rcu_node ->lock acquisition because the current task is guaranteed to stay put. This commit takes a small and paranoid step towards relying on this guarantee by placing a WARN_ON_ONCE() just after the early exit from the lock-acquisition loop. Signed-off-by: -
Paul E. McKenney authored
This commit removes a HOTPLUG_CPU #ifdef, replacing it with IS_ENABLED()-protected return statements. This relies on the optimizer to remove any resulting dead code. Signed-off-by: -
Ying Xue authored
This fixes the following sparse warnings: make C=1 CF=-D__CHECK_ENDIAN__ net/tipc/name_table.o net/tipc/name_table.c:977:17: error: incompatible types in comparison expression (different address spaces) net/tipc/name_table.c:977:17: error: incompatible types in comparison expression (different address spaces) To silence these spare complaints, an RCU annotation should be added to "next" pointer of hlist_node structure through hlist_next_rcu() macro when iterating over a hlist with hlist_for_each_entry_from_rcu(). Signed-off-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
Nicholas Mc Guire authored
rcu_cpu_has_callbacks() is declared int. The current declaration was introduced in commit c0f4dfd4 (rcu: Make RCU_FAST_NO_HZ take advantage of numbered callbacks). But it is actually returning bool and as the function description states " * Return true if the specified CPU has any callback....", this probably should be a bool as all (3) call-sites currently treat it as bool. Type-checking coccinelle spatches are being used to locate type mismatches between function signatures and return values in this case this produced: ./kernel/rcu/tree.c:3538 WARNING: return of wrong type int != bool, Patch was compile tested with x86_64_defconfig (implies CONFIG_TREE_RCU=y) Patch is against 4.1-rc3 (localversion-next is -next-20150511) and fixes Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Reviewed-by:
-
