s390/mm: fix vunmap vs finish_arch_post_lock_switch
authorMartin Schwidefsky <schwidefsky@de.ibm.com>
Mon, 6 Jun 2016 08:30:45 +0000 (10:30 +0200)
committerMartin Schwidefsky <schwidefsky@de.ibm.com>
Mon, 13 Jun 2016 13:58:21 +0000 (15:58 +0200)
commita9809407f6b6b4b55df7b6cf5522e39476b7e5e6
tree77fbe1921cbe1b71978b47d6eaf2742d1f46c73d
parentfd5ada04030cb584251c381cb70daa41e984ae82
s390/mm: fix vunmap vs finish_arch_post_lock_switch

The vunmap_pte_range() function calls ptep_get_and_clear() without any
locking. ptep_get_and_clear() uses ptep_xchg_lazy()/ptep_flush_direct()
for the page table update. ptep_flush_direct requires that preemption
is disabled, but without any locking this is not the case. If the kernel
preempts the task while the attach_counter is increased an endless loop
in finish_arch_post_lock_switch() will occur the next time the task is
scheduled.

Add explicit preempt_disable()/preempt_enable() calls to the relevant
functions in arch/s390/mm/pgtable.c.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
arch/s390/mm/pgtable.c