Commit 4e2cd8e6 authored by Valentin Schneider's avatar Valentin Schneider Committed by Zheng Zengkai
Browse files

s390: preempt: Fix preempt_count initialization

stable inclusion
from stable-5.10.50
commit ce04375e2d9b9e84d7d1e7b79ac29071e075c5d5
bugzilla: 174522 https://gitee.com/openeuler/kernel/issues/I4DNFY

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ce04375e2d9b9e84d7d1e7b79ac29071e075c5d5



--------------------------------

commit 6a942f57 upstream.

S390's init_idle_preempt_count(p, cpu) doesn't actually let us initialize the
preempt_count of the requested CPU's idle task: it unconditionally writes
to the current CPU's. This clearly conflicts with idle_threads_init(),
which intends to initialize *all* the idle tasks, including their
preempt_count (or their CPU's, if the arch uses a per-CPU preempt_count).

Unfortunately, it seems the way s390 does things doesn't let us initialize
every possible CPU's preempt_count early on, as the pages where this
resides are only allocated when a CPU is brought up and are freed when it
is brought down.

Let the arch-specific code set a CPU's preempt_count when its lowcore is
allocated, and turn init_idle_preempt_count() into an empty stub.

Fixes: f1a0a376 ("sched/core: Initialize the idle task with preemption disabled")
Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
Signed-off-by: default avatarValentin Schneider <valentin.schneider@arm.com>
Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
Reviewed-by: default avatarHeiko Carstens <hca@linux.ibm.com>
Link: https://lore.kernel.org/r/20210707163338.1623014-1-valentin.schneider@arm.com


Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: default avatarChen Jun <chenjun102@huawei.com>
Acked-by: default avatarWeilong Chen <chenweilong@huawei.com>
Signed-off-by: default avatarChen Jun <chenjun102@huawei.com>
Signed-off-by: default avatarZheng Zengkai <zhengzengkai@huawei.com>
parent 98e8d95a
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment