• Martin Schwidefsky's avatar
    s390/mm,tlb: race of lazy TLB flush vs. recreation of TLB entries · 53e857f3
    Martin Schwidefsky authored
    Git commit 050eef36 "[S390] fix tlb flushing vs. concurrent
    /proc accesses" introduced the attach counter to avoid using the
    mm_users value to decide between IPTE for every PTE and lazy TLB
    flushing with IDTE. That fixed the problem with mm_users but it
    introduced another subtle race, fortunately one that is very hard
    to hit.
    The background is the requirement of the architecture that a valid
    PTE may not be changed while it can be used concurrently by another
    cpu. The decision between IPTE and lazy TLB flushing needs to be
    done while the PTE is still valid. Now if the virtual cpu is
    temporarily stopped after the decision to use lazy TLB flushing but
    before the invalid bit of the PTE has been set, another cpu can attach
    the mm, find that flush_mm is set, do the IDTE, return to userspace,
    and recreate a TLB that uses the PTE in question. When the first,
    stopped cpu continues it will change the PTE while it is attached on
    another cpu. The first cpu will do another IDTE shortly after the
    modification of the PTE which makes the race window quite short.
    
    To fix this race the CPU that wants to attach the address space of a
    user space thread needs to wait for the end of the PTE modification.
    The number of concurrent TLB flushers for an mm is tracked in the
    upper 16 bits of the attach_count and finish_arch_post_lock_switch
    is used to wait for the end of the flush operation if required.
    Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
    53e857f3
mmu_context.h 2.78 KB