From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E911AC4361B for ; Mon, 14 Dec 2020 10:44:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C31FF22C7D for ; Mon, 14 Dec 2020 10:44:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394825AbgLNKo2 (ORCPT ); Mon, 14 Dec 2020 05:44:28 -0500 Received: from ozlabs.org ([203.11.71.1]:39793 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726889AbgLNKoR (ORCPT ); Mon, 14 Dec 2020 05:44:17 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4CvdK64kD7z9sS8; Mon, 14 Dec 2020 21:43:22 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1607942615; bh=BB2LOk7BKcW3B/GcIKz5tJ5Ofvtcaljnfs+I+V1L2/k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ojL3aBq9/eqFTY8e6grdkwE7Jw724cR+F6DZIuBDgyzJJWG/V3XZZA4dmxJEOnmeP 20A7tPpO36rq75nNkv3QTE5C4JPGc/TF7rCeOF4qhgpJ3WQnfNgjn1UVgDKUebOJNZ VY/WUU+XeHRPOVsDwi0cqRElFAAsNH4GEJOivhpnc5K8vTf5OrZsgtNcQZk/NZelWF PL0OtQFVWKxVMoORiBPq7Etg3MoHei2W+oNifrM1p4D2w44hWK5fyRA8VoVxegYkZH yN0mxWjO/HDU0oCYUo+FQwZJKZvIClQuuO5nrY3q2VFejCPX7OwCIpW52hVFj6+Ho4 h/WvrGyvKt3uw== From: Michael Ellerman To: Nicholas Piggin , Geert Uytterhoeven Cc: "Aneesh Kumar K.V" , Anton Vorontsov , Peter Zijlstra , Linux Kernel Mailing List , linuxppc-dev , Thomas Gleixner Subject: Re: [PATCH 2/2] powerpc/64s: Trim offlined CPUs from mm_cpumasks In-Reply-To: <1607919238.kj439g85v5.astroid@bobo.none> References: <20201120025757.325930-1-npiggin@gmail.com> <20201120025757.325930-3-npiggin@gmail.com> <1607919238.kj439g85v5.astroid@bobo.none> Date: Mon, 14 Dec 2020 21:43:21 +1100 Message-ID: <87h7oozn06.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Nicholas Piggin writes: > Excerpts from Geert Uytterhoeven's message of December 10, 2020 7:06 pm: >> Hi Nicholas, >> >> On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin wrote: >>> >>> When offlining a CPU, powerpc/64s does not flush TLBs, rather it just >>> leaves the CPU set in mm_cpumasks, so it continues to receive TLBIEs >>> to manage its TLBs. >>> >>> However the exit_flush_lazy_tlbs() function expects that after >>> returning, all CPUs (except self) have flushed TLBs for that mm, in >>> which case TLBIEL can be used for this flush. This breaks for offline >>> CPUs because they don't get the IPI to flush their TLB. This can lead >>> to stale translations. >>> >>> Fix this by clearing the CPU from mm_cpumasks, then flushing all TLBs >>> before going offline. >>> >>> These offlined CPU bits stuck in the cpumask also prevents the cpumask >>> from being trimmed back to local mode, which means continual broadcast >>> IPIs or TLBIEs are needed for TLB flushing. This patch prevents that >>> situation too. >>> >>> Signed-off-by: Nicholas Piggin >> >> Thanks for your patch! >> >>> --- a/arch/powerpc/platforms/powermac/smp.c >>> +++ b/arch/powerpc/platforms/powermac/smp.c >>> @@ -911,6 +911,8 @@ static int smp_core99_cpu_disable(void) >>> >>> mpic_cpu_set_priority(0xf); >>> >>> + cleanup_cpu_mmu_context(); >>> + >> >> I guess this change broke pmac32_defconfig+SMP in v5.10-rc7? >> >> arch/powerpc/platforms/powermac/smp.c: error: implicit >> declaration of function 'cleanup_cpu_mmu_context' >> [-Werror=implicit-function-declaration]: => 914:2 >> >> http://kisskb.ellerman.id.au/kisskb/buildresult/14423174/ > > Hey, yeah it does thanks for catching it. This patch fixes it for me > > --- > From a9b5ec92ffac975e81c6d7db6ff2b1486b2723f7 Mon Sep 17 00:00:00 2001 > From: Nicholas Piggin > Date: Mon, 14 Dec 2020 13:52:39 +1000 > Subject: [PATCH] powerpc/32s: Fix cleanup_cpu_mmu_context() compile bug > > 32s has no tlbiel_all() defined, so just disable the cleanup with a > comment. Or what about just: diff --git a/arch/powerpc/include/asm/book3s/32/mmu-hash.h b/arch/powerpc/include/asm/book3s/32/mmu-hash.h index 331187661236..685c589e723f 100644 --- a/arch/powerpc/include/asm/book3s/32/mmu-hash.h +++ b/arch/powerpc/include/asm/book3s/32/mmu-hash.h @@ -94,6 +94,7 @@ typedef struct { } mm_context_t; void update_bats(void); +static inline void cleanup_cpu_mmu_context(void) { }; /* patch sites */ extern s32 patch__hash_page_A0, patch__hash_page_A1, patch__hash_page_A2; cheers From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8F8FC4361B for ; Mon, 14 Dec 2020 10:45:49 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8C4A822C7D for ; Mon, 14 Dec 2020 10:45:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C4A822C7D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4CvdMs6YstzDqS7 for ; Mon, 14 Dec 2020 21:45:45 +1100 (AEDT) Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4CvdKM2swdzDqRb for ; Mon, 14 Dec 2020 21:43:35 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ellerman.id.au header.i=@ellerman.id.au header.a=rsa-sha256 header.s=201909 header.b=ojL3aBq9; dkim-atps=neutral Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4CvdK64kD7z9sS8; Mon, 14 Dec 2020 21:43:22 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1607942615; bh=BB2LOk7BKcW3B/GcIKz5tJ5Ofvtcaljnfs+I+V1L2/k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ojL3aBq9/eqFTY8e6grdkwE7Jw724cR+F6DZIuBDgyzJJWG/V3XZZA4dmxJEOnmeP 20A7tPpO36rq75nNkv3QTE5C4JPGc/TF7rCeOF4qhgpJ3WQnfNgjn1UVgDKUebOJNZ VY/WUU+XeHRPOVsDwi0cqRElFAAsNH4GEJOivhpnc5K8vTf5OrZsgtNcQZk/NZelWF PL0OtQFVWKxVMoORiBPq7Etg3MoHei2W+oNifrM1p4D2w44hWK5fyRA8VoVxegYkZH yN0mxWjO/HDU0oCYUo+FQwZJKZvIClQuuO5nrY3q2VFejCPX7OwCIpW52hVFj6+Ho4 h/WvrGyvKt3uw== From: Michael Ellerman To: Nicholas Piggin , Geert Uytterhoeven Subject: Re: [PATCH 2/2] powerpc/64s: Trim offlined CPUs from mm_cpumasks In-Reply-To: <1607919238.kj439g85v5.astroid@bobo.none> References: <20201120025757.325930-1-npiggin@gmail.com> <20201120025757.325930-3-npiggin@gmail.com> <1607919238.kj439g85v5.astroid@bobo.none> Date: Mon, 14 Dec 2020 21:43:21 +1100 Message-ID: <87h7oozn06.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Zijlstra , "Aneesh Kumar K.V" , Linux Kernel Mailing List , Anton Vorontsov , Thomas Gleixner , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Nicholas Piggin writes: > Excerpts from Geert Uytterhoeven's message of December 10, 2020 7:06 pm: >> Hi Nicholas, >> >> On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin wrote: >>> >>> When offlining a CPU, powerpc/64s does not flush TLBs, rather it just >>> leaves the CPU set in mm_cpumasks, so it continues to receive TLBIEs >>> to manage its TLBs. >>> >>> However the exit_flush_lazy_tlbs() function expects that after >>> returning, all CPUs (except self) have flushed TLBs for that mm, in >>> which case TLBIEL can be used for this flush. This breaks for offline >>> CPUs because they don't get the IPI to flush their TLB. This can lead >>> to stale translations. >>> >>> Fix this by clearing the CPU from mm_cpumasks, then flushing all TLBs >>> before going offline. >>> >>> These offlined CPU bits stuck in the cpumask also prevents the cpumask >>> from being trimmed back to local mode, which means continual broadcast >>> IPIs or TLBIEs are needed for TLB flushing. This patch prevents that >>> situation too. >>> >>> Signed-off-by: Nicholas Piggin >> >> Thanks for your patch! >> >>> --- a/arch/powerpc/platforms/powermac/smp.c >>> +++ b/arch/powerpc/platforms/powermac/smp.c >>> @@ -911,6 +911,8 @@ static int smp_core99_cpu_disable(void) >>> >>> mpic_cpu_set_priority(0xf); >>> >>> + cleanup_cpu_mmu_context(); >>> + >> >> I guess this change broke pmac32_defconfig+SMP in v5.10-rc7? >> >> arch/powerpc/platforms/powermac/smp.c: error: implicit >> declaration of function 'cleanup_cpu_mmu_context' >> [-Werror=implicit-function-declaration]: => 914:2 >> >> http://kisskb.ellerman.id.au/kisskb/buildresult/14423174/ > > Hey, yeah it does thanks for catching it. This patch fixes it for me > > --- > From a9b5ec92ffac975e81c6d7db6ff2b1486b2723f7 Mon Sep 17 00:00:00 2001 > From: Nicholas Piggin > Date: Mon, 14 Dec 2020 13:52:39 +1000 > Subject: [PATCH] powerpc/32s: Fix cleanup_cpu_mmu_context() compile bug > > 32s has no tlbiel_all() defined, so just disable the cleanup with a > comment. Or what about just: diff --git a/arch/powerpc/include/asm/book3s/32/mmu-hash.h b/arch/powerpc/include/asm/book3s/32/mmu-hash.h index 331187661236..685c589e723f 100644 --- a/arch/powerpc/include/asm/book3s/32/mmu-hash.h +++ b/arch/powerpc/include/asm/book3s/32/mmu-hash.h @@ -94,6 +94,7 @@ typedef struct { } mm_context_t; void update_bats(void); +static inline void cleanup_cpu_mmu_context(void) { }; /* patch sites */ extern s32 patch__hash_page_A0, patch__hash_page_A1, patch__hash_page_A2; cheers