From: Nicholas Piggin Date: Thu, 17 Dec 2020 13:47:28 +0000 (+1000) Subject: powerpc/64s/radix: Allow mm_cpumask trimming from external sources X-Git-Url: http://git.maquefel.me/?a=commitdiff_plain;h=780de40601aabeca41bc9aa717a329a77aa85e1a;p=linux.git powerpc/64s/radix: Allow mm_cpumask trimming from external sources mm_cpumask trimming is currently restricted to be issued by the current thread of a single-threaded mm. This patch relaxes that and allows the mask to be trimmed from any context. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201217134731.488135-5-npiggin@gmail.com --- diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c b/arch/powerpc/mm/book3s64/radix_tlb.c index 3d8b494c39f62..c27ef2ff89504 100644 --- a/arch/powerpc/mm/book3s64/radix_tlb.c +++ b/arch/powerpc/mm/book3s64/radix_tlb.c @@ -666,20 +666,16 @@ static void do_exit_flush_lazy_tlb(void *arg) } /* - * This IPI is only initiated from a CPU which is running mm which - * is a single-threaded process, so there will not be another racing - * IPI coming in where we would find our cpumask already clear. - * - * Nothing else clears our bit in the cpumask except CPU offlining, - * in which case we should not be taking IPIs here. However check - * this just in case the logic is wrong somewhere, and don't underflow - * the active_cpus count. + * This IPI may be initiated from any source including those not + * running the mm, so there may be a racing IPI that comes after + * this one which finds the cpumask already clear. Check and avoid + * underflowing the active_cpus count in that case. The race should + * not otherwise be a problem, but the TLB must be flushed because + * that's what the caller expects. */ if (cpumask_test_cpu(cpu, mm_cpumask(mm))) { atomic_dec(&mm->context.active_cpus); cpumask_clear_cpu(cpu, mm_cpumask(mm)); - } else { - WARN_ON_ONCE(1); } out_flush: