summaryrefslogtreecommitdiffstats
path: root/tools
diff options
context:
space:
mode:
authorHeiko Carstens <heiko.carstens@de.ibm.com>2012-05-09 09:37:30 +0200
committerMartin Schwidefsky <schwidefsky@de.ibm.com>2012-05-16 14:42:42 +0200
commitd5e50a51ccbda36b379aba9d1131a852eb908dda (patch)
tree1c23ccc1e5836c2ca5a85b930b34c04bf69d4875 /tools
parent473e66baad1e83e6c5dfdca65aba03bf21727202 (diff)
downloadlinux-d5e50a51ccbda36b379aba9d1131a852eb908dda.tar.bz2
s390/pfault: fix task state race
When setting the current task state to TASK_UNINTERRUPTIBLE this can race with a different cpu. The other cpu could set the task state after it inspected it (while it was still TASK_RUNNING) to TASK_RUNNING which would change the state from TASK_UNINTERRUPTIBLE to TASK_RUNNING again. This race was always present in the pfault interrupt code but didn't cause anything harmful before commit f2db2e6c "[S390] pfault: cpu hotplug vs missing completion interrupts" which relied on the fact that after setting the task state to TASK_UNINTERRUPTIBLE the task would really sleep. Since this is not necessarily the case the result may be a list corruption of the pfault_list or, as observed, a use-after-free bug while trying to access the task_struct of a task which terminated itself already. To fix this, we need to get a reference of the affected task when receiving the initial pfault interrupt and add special handling if we receive yet another initial pfault interrupt when the task is already enqueued in the pfault list. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: <stable@vger.kernel.org> # needed for v3.0 and newer Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions