s390/mm: Prevent possible preempt_count overflow

The s390 implementation of ptep_modify_prot_start() currently does
preempt_disable(), and the preempt_enable() is done later in
ptep_modify_prot_commit(). This logic is not really required, because the
PTE lock must be held over the complete prot_start/commit transaction,
as described in the comment of the generic implementation of
ptep_modify_prot_start().

That comment also mentions that this interface should be batchable,
and modify_prot_start_ptes() might start a transaction over a batch of
PTEs, implemented as a simple loop over ptep_modify_prot_start().
In this case, the preempt_disable() in ptep_modify_prot_start() would
be called multiple times, before the corresponding preempt_enable()
calls happen, and this can lead to a preempt_count overflow.

To fix this, simply remove the preempt_disable/enable() calls in
ptep_modify_prot_start/commit(), and rely on the PTE lock being held.

Commit cac1db8c3aad ("mm: optimize mprotect() by PTE batching") made use
of this PTE batching for the first time, and triggers warnings like this:

 DEBUG_LOCKS_WARN_ON((preempt_count() & PREEMPT_MASK) >= PREEMPT_MASK - 10)
 BUG: sleeping function called from invalid context at mm/mprotect.c:576

Hence, add a Fixes tag on that commit. Not because it is broken, but to
make sure that it won't get backported w/o also this fix for s390.

Fixes: cac1db8c3aad ("mm: optimize mprotect() by PTE batching")
Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>

0 files changed, 0 insertions, 0 deletions