linux-kernel - Re: [PATCHv2 2/2] kernel/kexec: Stop all userspace deadline tasks

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: <20251028163911.98990cbf1516d1c6d221f92b@linux-foundation.org>
Date: Tue, 28 Oct 2025 16:39:11 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Pingfan Liu <piliu@...hat.com>
Cc: kexec@...ts.infradead.org, linux-kernel@...r.kernel.org, Waiman Long
 <longman@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Juri Lelli
 <juri.lelli@...hat.com>, Pierre Gondois <pierre.gondois@....com>, Baoquan
 He <bhe@...hat.com>, Ingo Molnar <mingo@...hat.com>, Vincent Guittot
 <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>,
 Steven Rostedt <rostedt@...dmis.org>, Valentin Schneider
 <vschneid@...hat.com>, "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
 Joel Granados <joel.granados@...nel.org>, Thomas Gleixner
 <tglx@...utronix.de>
Subject: Re: [PATCHv2 2/2] kernel/kexec: Stop all userspace deadline tasks

On Tue, 28 Oct 2025 11:09:14 +0800 Pingfan Liu <piliu@...hat.com> wrote:

> Now that the deadline bandwidth check has been skipped, there is nothing
> to prevent CPUs from being unplugged. But as deadline tasks are crowded
> onto the remaining CPUs, they may starve normal tasks, especially the
> hotplug kthreads. As a result, the kexec process will hang indefinitely.
> 
> Send SIGSTOP to all userspace deadline tasks at the beginning of kexec
> to allow other tasks to run as CPUs are unplugged.

This all looks a bit hacky.

What's special about kexec?  If many CPUs are being unplugged via other
means, won't the kernel still hit the very problems which are being
addressed here for kexec?  If so, we should seek a general fix for these
issues rather than a kexec-specific one?

> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1132,6 +1132,18 @@ bool kexec_load_permitted(int kexec_image_type)
>  	return true;
>  }
>  
> +static void stop_user_deadline_tasks(void)
> +{
> +	struct task_struct *task;
> +
> +	rcu_read_lock();
> +	for_each_process(task) {
> +		if (task->policy == SCHED_DEADLINE && task->mm)
> +			send_sig(SIGSTOP, task, 1);
> +	}
> +	rcu_read_unlock();
> +}

If we can safely stop all SCHED_DEADLINE user tasks then presumably we
can safely stop all user tasks.  Why not do that?

>  /*
>   * Move into place and start executing a preloaded standalone
>   * executable.  If nothing was preloaded return an error.
> @@ -1190,6 +1202,11 @@ int kernel_kexec(void)
>  		cpu_hotplug_disable();
>  		kexec_in_progress = true;
>  		cpu_hotplug_enable();
> +		/*
> +		 * As CPU hot-removal, the crowed deadline task may starve other
> +		 * tasks. So stop them.
> +		 */
> +		stop_user_deadline_tasks();
>  		kernel_restart_prepare("kexec reboot");
>  		migrate_to_reboot_cpu();
>  		syscore_shutdown();
y