When a task performs a fork operation, the PKRU value of the newly forked
task is set to the value read from hardware. At this point, if the service
is executing rpal_pkey_setup(), the newly forked task has not yet been
added to the task list, so PKRU settings cannot be synchronized to the new
task. This results in the new task's PKRU not being set to the correct
value when it is woken up.
This patch addresses this issue by:
- After the newly forked task is added to the task list, further updating
its PKRU value.
- Acquiring a mutex lock to ensure that the PKRU update occurs either
before or after the invocation of rpal_pkey_setup(). This avoids race
conditions with rpal_pkey_setup() and guarantees that the re-updated PKRU
value is always correct.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
kernel/fork.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index 01cd48eadf68..11cba74d07c8 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2683,6 +2683,19 @@ __latent_entropy struct task_struct *copy_process(
syscall_tracepoint_update(p);
write_unlock_irq(&tasklist_lock);
+#ifdef CONFIG_RPAL_PKU
+ do {
+ struct rpal_service *cur = rpal_current_service();
+
+ if (cur) {
+ /* ensure we are not in rpal_enable_service() */
+ mutex_lock(&cur->mutex);
+ p->thread.pkru = rdpkru();
+ mutex_unlock(&cur->mutex);
+ }
+ } while (0);
+#endif
+
if (pidfile)
fd_install(pidfd, pidfile);
--
2.20.1
