]> git.karo-electronics.de Git - karo-tx-linux.git/commit
s390/pfault: fix task state race
authorHeiko Carstens <heiko.carstens@de.ibm.com>
Wed, 9 May 2012 07:37:30 +0000 (09:37 +0200)
committerBen Hutchings <ben@decadent.org.uk>
Wed, 30 May 2012 23:43:28 +0000 (00:43 +0100)
commit559dd7d5b6fee151313910afbe3f19ceaf18dc9b
treeadd75129d4f3dd63c4037d37a3bbd3abc17e8b9f
parent47ca08df8af6387c4b31639b648bb740e3e36b93
s390/pfault: fix task state race

commit d5e50a51ccbda36b379aba9d1131a852eb908dda upstream.

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>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
arch/s390/mm/fault.c