PR_SCHED_CORE_GET converts the internal core scheduling cookie to an
opaque userspace value with ptr_to_hashval().
When the pointer hash key is not initialized yet, ptr_to_hashval()
returns -EBUSY without storing a hash. PR_SCHED_CORE_GET currently
ignores this error and returns the zero-initialized id instead. Since
cookie 0 denotes the default core scheduling cookie, this reports
incorrect state to userspace.
Propagate the hashing error and make the scheduler selftest retry the
transient EBUSY. Do not wait for RNG initialization in
PR_SCHED_CORE_GET; ptr_to_hashval() already reports an unavailable
pointer hash key as -EBUSY, so propagate that condition through the
prctl interface.
Testing on x86_64 QEMU reproduced the bug during an entropy-starved
early boot:
Before:
CREATE ret=0 errno=0 (Success)
GET ret=0 errno=0 (Success) cookie=0x0000000000000000
After patch 1:
CREATE ret=0 errno=0 (Success)
GET ret=-1 errno=16 (Device or resource busy)
The unfixed cs_prctl_test failed seven cookie assertions in the same
setup. With normal random initialization, the fixed kernel and updated
selftest completed successfully:
SUCCESS !!!
TEST_RESULT=PASS
Hui Su (2):
sched/core: Propagate pointer hash errors from PR_SCHED_CORE_GET
selftests/sched: Retry PR_SCHED_CORE_GET on EBUSY
kernel/sched/core_sched.c | 5 ++--
tools/testing/selftests/sched/cs_prctl_test.c | 27 ++++++++++++++-----
2 files changed, 23 insertions(+), 9 deletions(-)
base-commit: cba2348ab114391f5b1a00fa65c5b739f13f0563
--
2.55.0
