Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit c6a5b958 authored by Pavankumar Kondeti's avatar Pavankumar Kondeti Committed by Gerrit - the friendly Code Review server
Browse files

sched/walt: Fix use after free in trace_sched_update_task_ravg()



commit 4d09122c1868 ("sched: Fix spinlock recursion in sched_exit()")
moved freeing of task's current and previous window arrays outside
the rq->lock. These arrays can be accessed from another CPU in parallel
and end up using freed memory. For example,

CPU#0                                 CPU#1
----------------------------------    -------------------------------
sched_exit()                          try_to_wake_up()--> The task wakes
                                                          up on CPU#0
 task_rq_lock()                        set_task_cpu()
                                        fixup_busy_time() --> waiting for
					                  CPU#0's rq->lock

 task_rq_unlock()                       fixup_busy_time()-->lock acquired
 free_task_load_ptrs()
  kfree(p->ravg.curr_window_cpu)         update_task_ravg()-->called on
                                                          current of CPU#0
					  trace_sched_update_task_ravg()
					          --> access freed memory
  p->ravg.curr_window_cpu = NULL;

To fix this issue, window array pointers must be set to NULL before
freeing the memory. Since this happens outside the lock, memory barriers
are needed on write and read paths. A much simpler alternative would be
skipping update_task_ravg() trace point for tasks that are marked as dead.
The window stats of dead tasks are not updated any ways. While at it, skip
this trace point for newly created tasks for which also window stats are
not updated.

Change-Id: I4d7cb8a3cf7cf84270b09721140d35205643b7ab
Signed-off-by: default avatarPavankumar Kondeti <pkondeti@codeaurora.org>
[spathi@codeaurora.org: moved changes to hmp.c since EAS is not supported]
Signed-off-by: default avatarSrinivasarao P <spathi@codeaurora.org>
parent cb0e8e7c
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment