linux-kernel - Re: [PATCH v3] sched: Provide Kconfig support for default dynamic preempt mode

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YYuvzzZPuIZPe2iU@elver.google.com>
Date:   Wed, 10 Nov 2021 12:41:03 +0100
From:   Marco Elver <elver@...gle.com>
To:     Frederic Weisbecker <frederic@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH v3] sched: Provide Kconfig support for default dynamic
 preempt mode

On Tue, Sep 14, 2021 at 12:31PM +0200, Frederic Weisbecker wrote:
> Currently the boot defined preempt behaviour (aka dynamic preempt)
> selects full preemption by default when the "preempt=" boot parameter
> is omitted. However distros may rather want to default to either
> no preemption or voluntary preemption.
> 
> To provide with this flexibility, make dynamic preemption a visible
> Kconfig option and adapt the preemption behaviour selected by the user
> to either static or dynamic preemption.
> 
> Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
> ---
>  kernel/Kconfig.preempt | 32 +++++++++++++++++++++++---------
>  kernel/sched/core.c    | 29 ++++++++++++++++++++++++++---
>  2 files changed, 49 insertions(+), 12 deletions(-)
> 
> diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
> index 5876e30c5740..60f1bfc3c7b2 100644
> --- a/kernel/Kconfig.preempt
> +++ b/kernel/Kconfig.preempt
> @@ -2,10 +2,11 @@
>  
>  choice
>  	prompt "Preemption Model"
> -	default PREEMPT_NONE
> +	default PREEMPT_NONE_BEHAVIOUR
>  
> -config PREEMPT_NONE
> +config PREEMPT_NONE_BEHAVIOUR
>  	bool "No Forced Preemption (Server)"
> +	select PREEMPT_NONE if !PREEMPT_DYNAMIC
>  	help
>  	  This is the traditional Linux preemption model, geared towards
>  	  throughput. It will still provide good latencies most of the
> @@ -17,9 +18,10 @@ config PREEMPT_NONE
>  	  raw processing power of the kernel, irrespective of scheduling
>  	  latencies.
>  
> -config PREEMPT_VOLUNTARY
> +config PREEMPT_VOLUNTARY_BEHAVIOUR
>  	bool "Voluntary Kernel Preemption (Desktop)"
>  	depends on !ARCH_NO_PREEMPT
> +	select PREEMPT_VOLUNTARY if !PREEMPT_DYNAMIC
>  	help
>  	  This option reduces the latency of the kernel by adding more
>  	  "explicit preemption points" to the kernel code. These new
> @@ -35,12 +37,10 @@ config PREEMPT_VOLUNTARY
>  
>  	  Select this if you are building a kernel for a desktop system.
>  
> -config PREEMPT
> +config PREEMPT_BEHAVIOUR
>  	bool "Preemptible Kernel (Low-Latency Desktop)"
>  	depends on !ARCH_NO_PREEMPT
> -	select PREEMPTION
> -	select UNINLINE_SPIN_UNLOCK if !ARCH_INLINE_SPIN_UNLOCK
> -	select PREEMPT_DYNAMIC if HAVE_PREEMPT_DYNAMIC
> +	select PREEMPT
>  	help
>  	  This option reduces the latency of the kernel by making
>  	  all kernel code (that is not executing in a critical section)
> @@ -58,7 +58,7 @@ config PREEMPT
>  
>  config PREEMPT_RT
>  	bool "Fully Preemptible Kernel (Real-Time)"
> -	depends on EXPERT && ARCH_SUPPORTS_RT
> +	depends on EXPERT && ARCH_SUPPORTS_RT && !PREEMPT_DYNAMIC
>  	select PREEMPTION
>  	help
>  	  This option turns the kernel into a real-time kernel by replacing
> @@ -75,6 +75,17 @@ config PREEMPT_RT
>  
>  endchoice
>  
> +config PREEMPT_NONE
> +	bool
> +
> +config PREEMPT_VOLUNTARY
> +	bool
> +
> +config PREEMPT
> +	bool
> +	select PREEMPTION
> +	select UNINLINE_SPIN_UNLOCK if !ARCH_INLINE_SPIN_UNLOCK

This change landed in mainline, and I only noticed this because I've
been staring at configs too much and the preemption of some test kernels
(syzbot) has changed.

Those are "just" test kernels for now, but I expect this to proliferate
to a significant number of other configs with automated scripts
accepting new default config values or inattentive humans.

My bet is that some major distros will accidentally configure the
defaults and instead of 'full'/'voluntary' preemption will end up with
'none' as the default.

The main problem is that PREEMPT_NONE/PREEMPT_VOLUNATRY/PREEMPT are no
longer user-settable and are only selectable by other config options.
Because the *_BEHAVIOUR configs are new, the default will be
PREEMPT_NONE_BEHAVIOUR.

For example, an old 5.15 config has:

	$ grep PREEMPT .config
	# CONFIG_PREEMPT_NONE is not set
	CONFIG_PREEMPT_VOLUNTARY=y
	# CONFIG_PREEMPT is not set
	CONFIG_HAVE_PREEMPT_DYNAMIC=y
	# CONFIG_PREEMPTIRQ_DELAY_TEST is not set

A new 5.16 config with this patch, after migrating the old config:

	$ yes '' | make oldconfig
	$ grep PREEMPT .config
	CONFIG_PREEMPT_NONE_BEHAVIOUR=y
	# CONFIG_PREEMPT_VOLUNTARY_BEHAVIOUR is not set
	# CONFIG_PREEMPT_BEHAVIOUR is not set
	CONFIG_PREEMPT=y
	CONFIG_PREEMPT_COUNT=y
	CONFIG_PREEMPTION=y
	CONFIG_PREEMPT_DYNAMIC=y
	CONFIG_PREEMPT_RCU=y
	CONFIG_HAVE_PREEMPT_DYNAMIC=y
	CONFIG_DEBUG_PREEMPT=y
	# CONFIG_PREEMPT_TRACER is not set
	# CONFIG_PREEMPTIRQ_DELAY_TEST is not set

Is there some way to avoid introducing *_BEHAVIOUR and keep the old
user-settable config options?

That would make the transition more seamless and avoid this predictable
issue when 5.16 is released.

Thanks,
-- Marco