Re: [PATCH for-v7.5 12/14] rcutorture: Enable RCU_BOOST where supported

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [Medium] rcutorture: promptless RCU_BOOST default y breaks
  BUSTED-BOOST negative test
- [Medium] rcutorture: unintended rcu_torture_boost() activation in
  NOCB01 and NOCB02
- [Low] rcu: Kconfig exposes RCU_BOOST_DELAY prompt when RCU_EXPERT=n
--

commit d21fbe9cdf60a4b081f0f993ea961ee602b93a2c
Author: Paul E. McKenney <paulmck@kernel.org>

rcutorture: Enable RCU_BOOST where supported

This commit drops the RCU_EXPERT dependency and prompt from RCU_BOOST so
that it is automatically enabled whenever RT_MUTEXES and PREEMPT_RCU
(or PREEMPT_RT) are enabled, and removes CONFIG_RCU_BOOST=n from
rcutorture config fragments.

> diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig
> index bc9483c0b5d84..7b605fa1f576e 100644
> --- a/kernel/rcu/Kconfig
> +++ b/kernel/rcu/Kconfig
> @@ -237,17 +237,15 @@ config RCU_FANOUT_LEAF
>  	  Take the default if unsure.
>  
>  config RCU_BOOST
> -	bool "Enable RCU priority boosting"
> -	depends on (RT_MUTEXES && PREEMPT_RCU && RCU_EXPERT) || PREEMPT_RT
> -	default y if PREEMPT_RT
> +	bool
> +	default y if (RT_MUTEXES && PREEMPT_RCU) || PREEMPT_RT

[Severity: Medium]
Does making RCU_BOOST a promptless symbol that defaults to y break the
BUSTED-BOOST rcutorture negative test added in d4240d628f98 ("rcutorture:
Add BUSTED-BOOST to test RCU priority boosting tests")?

BUSTED-BOOST sets CONFIG_PREEMPT=y (selecting CONFIG_PREEMPT_RCU=y) and
passes rcutorture.test_boost=2 so rcu_torture_can_boost() runs the boost
test on a kernel with CONFIG_RCU_BOOST=n to verify boost-failure
detection.  With this change, BUSTED-BOOST builds with CONFIG_RCU_BOOST=y
and cannot override it in its config fragment, so priority boosting is
active and the negative test passes instead of failing.

>  	help
>  	  This option boosts the priority of preempted RCU readers that
>  	  block the current preemptible RCU grace period for too long.
>  	  This option also prevents heavy loads from blocking RCU
> -	  callback invocation.
> +	  callback invocation.  It is now automatically enabled in
> +	  any kernel that can benefit from it and that can support it.
>  
> -	  Say Y here if you are working with real-time apps or heavy loads
> -	  Say N here if you are unsure.
>  
>  config RCU_BOOST_DELAY
>  	int "Milliseconds to delay boosting after RCU grace-period start"

[Severity: Low]
Will enabling RCU_BOOST when CONFIG_RCU_EXPERT=n expose the
RCU_BOOST_DELAY (and RCU_NOCB_CPU_CB_BOOST when NO_HZ_FULL selects
RCU_NOCB_CPU) prompts during make oldconfig on non-expert configurations?

Both options depend on RCU_BOOST and have unconditional prompts that were
previously hidden when RCU_EXPERT=n kept RCU_BOOST disabled.  Since
kernel/rcu/tree_plugin.h uses CONFIG_RCU_BOOST_DELAY unconditionally under
#ifdef CONFIG_RCU_BOOST, gating their prompts with "if RCU_EXPERT" would
keep the default value defined without prompting non-expert users.

> diff --git a/tools/testing/selftests/rcutorture/configs/rcu/NOCB01 b/tools/testing/selftests/rcutorture/configs/rcu/NOCB01
> index bbe6d28210ab5..91ca7e8b5725f 100644
> --- a/tools/testing/selftests/rcutorture/configs/rcu/NOCB01
> +++ b/tools/testing/selftests/rcutorture/configs/rcu/NOCB01
> @@ -14,7 +14,6 @@ CONFIG_RCU_FANOUT_LEAF=2
>  CONFIG_RCU_NOCB_CPU=y
>  CONFIG_DEBUG_LOCK_ALLOC=n
>  CONFIG_PROVE_LOCKING=n
> -CONFIG_RCU_BOOST=n
>  CONFIG_DEBUG_OBJECTS_RCU_HEAD=n
>  CONFIG_RCU_EXPERT=y
>  CONFIG_RCU_EQS_DEBUG=y
> diff --git a/tools/testing/selftests/rcutorture/configs/rcu/NOCB02 b/tools/testing/selftests/rcutorture/configs/rcu/NOCB02
> index 4c2b8cd6d8fdb..ed3f3f7b29e73 100644
> --- a/tools/testing/selftests/rcutorture/configs/rcu/NOCB02
> +++ b/tools/testing/selftests/rcutorture/configs/rcu/NOCB02
> @@ -14,7 +14,6 @@ CONFIG_RCU_FANOUT_LEAF=2
>  CONFIG_RCU_NOCB_CPU=y
>  CONFIG_DEBUG_LOCK_ALLOC=n
>  CONFIG_PROVE_LOCKING=n
> -CONFIG_RCU_BOOST=n
>  CONFIG_DEBUG_OBJECTS_RCU_HEAD=n
>  CONFIG_RCU_EXPERT=y
>  CONFIG_RCU_EQS_DEBUG=y

[Severity: Medium]
Does enabling CONFIG_RCU_BOOST=y in NOCB01 and NOCB02 unintentionally
start rcu_torture_boost() stress threads on these scenarios?

With CONFIG_RCU_TORTURE_TEST=y and CONFIG_RCU_BOOST=y,
sanitize_kthread_prio() raises kthread_prio to 2 and
rcu_torture_can_boost() returns true by default, spawning per-CPU
SCHED_FIFO rcu_torture_boost() threads on scenarios that leave rcuop
kthreads at SCHED_NORMAL without CONFIG_RCU_NOCB_CPU_CB_BOOST=y.  The
follow-up commit "rcutorture: Disable RCU priority boost testing on
non-TREE03 scenarios" adds rcutorture.test_boost=0 to TREE01, TREE02,
TREE08, and TREE09, but omits NOCB01.boot and NOCB02.boot.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261113005747.2977123-1-jfern@kernel.org?part=12