PR_SCHED_CORE_GET hashes the internal core scheduling cookie before
returning an opaque identifier to userspace.
ptr_to_hashval() returns -EBUSY until the random key used for pointer
hashing has been initialized. However, PR_SCHED_CORE_GET currently
ignores that return value.
Since id is initialized to zero, a failed hash is therefore reported
as a successful GET with cookie 0. Cookie 0 represents the default
core scheduling cookie, so a task which already has a core scheduling
cookie can temporarily appear to have the default cookie during early
boot.
Propagate errors from ptr_to_hashval() instead. In particular, this
allows userspace to retry PR_SCHED_CORE_GET when pointer hashing is
temporarily unavailable.
An early-boot x86_64 QEMU reproducer observed the following before the
fix:
CREATE ret=0 errno=0 (Success)
GET ret=0 errno=0 (Success) cookie=0x0000000000000000
With this fix, the same GET correctly returned:
GET ret=-1 errno=16 (Device or resource busy)
The full cs_prctl_test also failed seven cookie assertions on the
unfixed kernel after PR_SCHED_CORE_CREATE succeeded but subsequent GETs
continued to report cookie 0.
Fixes: 7ac592aa35a6 ("sched: prctl() core-scheduling interface")
Cc: [email protected]
Signed-off-by: Hui Su <[email protected]>
---
kernel/sched/core_sched.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/core_sched.c b/kernel/sched/core_sched.c
index 43e0bde3038e..f119a2973ca8 100644
--- a/kernel/sched/core_sched.c
+++ b/kernel/sched/core_sched.c
@@ -177,8 +177,9 @@ int sched_core_share_pid(unsigned int cmd, pid_t pid, enum
pid_type type,
}
cookie = sched_core_clone_cookie(task);
if (cookie) {
- /* XXX improve ? */
- ptr_to_hashval((void *)cookie, &id);
+ err = ptr_to_hashval((void *)cookie, &id);
+ if (err)
+ goto out;
}
err = put_user(id, (u64 __user *)uaddr);
goto out;
--
2.55.0
