Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- Return-Path: <fbarrat@linux.ibm.com>
- Received: from g01zcilapp002.ahe.pok.ibm.com ([unix socket])
- by g01zcilapp002 (Cyrus v2.3.11) with LMTPA;
- Tue, 31 Jul 2018 09:24:55 -0400
- X-Sieve: CMU Sieve 2.3
- Received: from localhost (localhost [127.0.0.1])
- by g01zcilapp002.ahe.pok.ibm.com (Postfix) with ESMTP id B05D92607C;
- Tue, 31 Jul 2018 09:24:55 -0400 (EDT)
- X-Virus-Scanned: amavisd-new at linux.ibm.com
- X-Spam-Flag: NO
- X-Spam-Score: -1
- X-Spam-Level:
- X-Spam-Status: No, score=-1 tagged_above=-9999 required=6.2
- tests=[ALL_TRUSTED=-1] autolearn=disabled
- Received: from g01zcilapp002.ahe.pok.ibm.com ([127.0.0.1])
- by localhost (g01zcilapp002.ahe.pok.ibm.com [127.0.0.1]) (amavisd-new, port 10024)
- with LMTP id 9-GI_G-McCEv; Tue, 31 Jul 2018 09:24:55 -0400 (EDT)
- Received: from g01zcilapp001.ahe.pok.ibm.com (g01zcilapp001.ahe.pok.ibm.com [9.63.16.68])
- by g01zcilapp002.ahe.pok.ibm.com (Postfix) with ESMTP id 2D01926064;
- Tue, 31 Jul 2018 09:24:55 -0400 (EDT)
- Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196])
- by g01zcilapp001.ahe.pok.ibm.com (Postfix) with ESMTP id ECFE313E002;
- Tue, 31 Jul 2018 09:24:54 -0400 (EDT)
- Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62])
- by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w6VDOsGF23593046
- (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL);
- Tue, 31 Jul 2018 13:24:54 GMT
- Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])
- by IMSVA (Postfix) with ESMTP id 013C5AE04D;
- Tue, 31 Jul 2018 16:24:56 +0100 (BST)
- Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])
- by IMSVA (Postfix) with ESMTP id DCFBDAE055;
- Tue, 31 Jul 2018 16:24:54 +0100 (BST)
- Received: from borneo.ttt.fr.ibm.com (unknown [9.143.107.186])
- by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP;
- Tue, 31 Jul 2018 16:24:54 +0100 (BST)
- From: Frederic Barrat <fbarrat@linux.ibm.com>
- To: linuxppc-dev@lists.ozlabs.org, vaibhav@linux.ibm.com, npiggin@gmail.com
- Cc: felix@linux.ibm.com, clombard@linux.ibm.com
- Subject: [PATCH] powerpc/64s/radix: Fix missing global invalidations when removing copro
- Date: Tue, 31 Jul 2018 15:24:52 +0200
- Message-Id: <20180731132452.15994-1-fbarrat@linux.ibm.com>
- X-Mailer: git-send-email 2.17.1
- X-TM-AS-GCONF: 00
- With the optimizations for TLB invalidation from commit 0cef77c7798a
- ("powerpc/64s/radix: flush remote CPUs out of single-threaded
- mm_cpumask"), the scope of a TLBI (global vs. local) can now be
- influenced by the value of the 'copros' counter of the memory context.
- When calling mm_context_remove_copro(), the 'copros' counter is
- decremented first before flushing. It may have the unintended side
- effect of sending local TLBIs when we explicitly need global
- invalidations in this case. Thus breaking any nMMU user in a bad and
- unpredictable way.
- Fix it by flushing first, before updating the 'copros' counter, so
- that invalidations will be global.
- Fixes: 0cef77c7798a ("powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask")
- Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
- ---
- arch/powerpc/include/asm/mmu_context.h | 33 ++++++++++++++++----------
- 1 file changed, 21 insertions(+), 12 deletions(-)
- diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
- index 79d570cbf332..b2f89b621b15 100644
- --- a/arch/powerpc/include/asm/mmu_context.h
- +++ b/arch/powerpc/include/asm/mmu_context.h
- @@ -143,24 +143,33 @@ static inline void mm_context_remove_copro(struct mm_struct *mm)
- {
- int c;
- - c = atomic_dec_if_positive(&mm->context.copros);
- -
- - /* Detect imbalance between add and remove */
- - WARN_ON(c < 0);
- -
- /*
- - * Need to broadcast a global flush of the full mm before
- - * decrementing active_cpus count, as the next TLBI may be
- - * local and the nMMU and/or PSL need to be cleaned up.
- - * Should be rare enough so that it's acceptable.
- + * When removing the last copro, we need to broadcast a global
- + * flush of the full mm, as the next TLBI may be local and the
- + * nMMU and/or PSL need to be cleaned up.
- + *
- + * Both the 'copros' and 'active_cpus' counts are looked at in
- + * flush_all_mm() to determine the scope (local/global) of the
- + * TLBIs, so we need to flush first before decrementing
- + * 'copros'. If this API is used by several callers for the
- + * same context, it can lead to over-flushing. It's hopefully
- + * not common enough to be a problem.
- *
- * Skip on hash, as we don't know how to do the proper flush
- * for the time being. Invalidations will remain global if
- - * used on hash.
- + * used on hash. Note that we can't drop 'copros' either, as
- + * it could make some invalidations local with no flush
- + * in-between.
- */
- - if (c == 0 && radix_enabled()) {
- + if (radix_enabled()) {
- flush_all_mm(mm);
- - dec_mm_active_cpus(mm);
- +
- + c = atomic_dec_if_positive(&mm->context.copros);
- + /* Detect imbalance between add and remove */
- + WARN_ON(c < 0);
- +
- + if (c == 0)
- + dec_mm_active_cpus(mm);
- }
- }
- #else
- --
- 2.17.1
Add Comment
Please, Sign In to add comment