Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4861136yba; Tue, 30 Apr 2019 05:40:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqxQdPWsiedMGFwYMFUQIuzgMPW9sAeKJ3iwg5+pcd25st/uEdS2fMYOoKoigLgVjhYCXE1I X-Received: by 2002:a63:a1f:: with SMTP id 31mr66654823pgk.427.1556628031768; Tue, 30 Apr 2019 05:40:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556628031; cv=none; d=google.com; s=arc-20160816; b=1J+v4DqEO9QTsFHG+3FVvz7SA9wTX47QkHeyvX/CGnKTsZGIGOLQmGFWa6E5MjL08A 9q4XRVjms5owC5U+/D+Efkf2ySi4VoA9GjMBeHHu/HjgmVPr7PSH65ylYvpZ9ARP5zLs GoUdLluszUIOgoJnwvQY71qvEMun7Xw2b9rNhOnGXXseEC46sQZ12kBTDJ4YhkR3CG+y sxPIcumyTmRN8kqVt76lagQQAMCoVzlBx3IzFCAO9FOgG6xM6Nwv32nAfSyLr6ziTB0/ lT+6zMq46cPoeYJg1v/vyw45JteGdT1bQUqbpTOkK4mXpndzHkKljBDgkDI9GKCQNZ/F wBmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:cc:to:subject:from:references :in-reply-to:message-id:dkim-signature; bh=nyn5PbqqhKTzRamqkQ3I4adO6bi1wUC9r3Z2MBImYHM=; b=fagioM2Y4HebYs7Q9TN1u/bCHBkl6KM/gICflGcXm8XmI5DKtA5p0+ZgUJQym4SIeW iJAQsX1uf6+K8hSIvOfM2k4w8BHbVOyB4gD2qYpkAufFVAOVddncycomWLsKa2ObwbWP Hb7zT06s5LuMNGijFDyA7m1/I9ftuwUdPGppA7p2BqMinyWNaIr8ktBAu7WWvCJzQ4Dl QKTuHxy+pGJF76N8q73EfJOIPeKGziXdM0Zy0fAq8zheDPfK/P2NfXjds4ey4V/egYz1 O0GI9VQpTKu2i1S0qx7nlhkcrnuSYJGvnXgAg1ERif42fR3TeG2px5NuSByxoROJ/l6G eShg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@c-s.fr header.s=mail header.b="R/6PPSdm"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n21si28472606pgl.233.2019.04.30.05.40.15; Tue, 30 Apr 2019 05:40:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@c-s.fr header.s=mail header.b="R/6PPSdm"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728277AbfD3MjJ (ORCPT + 99 others); Tue, 30 Apr 2019 08:39:09 -0400 Received: from pegase1.c-s.fr ([93.17.236.30]:46452 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728212AbfD3MjI (ORCPT ); Tue, 30 Apr 2019 08:39:08 -0400 Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 44th0m65ppz9vD38; Tue, 30 Apr 2019 14:39:04 +0200 (CEST) Authentication-Results: localhost; dkim=pass reason="1024-bit key; insecure key" header.d=c-s.fr header.i=@c-s.fr header.b=R/6PPSdm; dkim-adsp=pass; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id beeXf01hbNiG; Tue, 30 Apr 2019 14:39:04 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 44th0m54ftz9vD30; Tue, 30 Apr 2019 14:39:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c-s.fr; s=mail; t=1556627944; bh=nyn5PbqqhKTzRamqkQ3I4adO6bi1wUC9r3Z2MBImYHM=; h=In-Reply-To:References:From:Subject:To:Cc:Date:From; b=R/6PPSdmoZ5NAyiTzibrVYDs+LWf6peMGsGja1FzLfUaXr0uR03458Ccu+LjW6l6L FiQRZShCWNqCOiW96vULutGUYPJMu/8pwwYPcdDRFLqOxAaYDy2bvE4wSWgfTqDE7p tvmD7dS/yKSGSf4WnLUULND++03zCwyoDYj2H7yQ= Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id EF4D48B8E1; Tue, 30 Apr 2019 14:39:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id LCQMn-uA0xdE; Tue, 30 Apr 2019 14:39:05 +0200 (CEST) Received: from po16846vm.idsi0.si.c-s.fr (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id CC76E8B8DF; Tue, 30 Apr 2019 14:39:05 +0200 (CEST) Received: by po16846vm.idsi0.si.c-s.fr (Postfix, from userid 0) id 91C83666F8; Tue, 30 Apr 2019 12:39:05 +0000 (UTC) Message-Id: <5e4c040b7c1f89b960bd5df2d7eb073bcd72c96d.1556627571.git.christophe.leroy@c-s.fr> In-Reply-To: References: From: Christophe Leroy Subject: [PATCH v3 16/16] powerpc/32: Don't add dummy frames when calling trace_hardirqs_on/off To: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Nicholas Piggin Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Date: Tue, 30 Apr 2019 12:39:05 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org No need to add dummy frames when calling trace_hardirqs_on or trace_hardirqs_off. GCC properly handles empty stacks. In addition, powerpc doesn't set CONFIG_FRAME_POINTER, therefore __builtin_return_address(1..) returns NULL at all time. So the dummy frames are definitely unneeded here. In the meantime, avoid reading memory for loading r1 with a value we already know. Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/entry_32.S | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index e65c3e70c648..235a01d34b6d 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -243,12 +243,7 @@ transfer_to_handler_cont: reenable_mmu: /* - * The trace_hardirqs_off will use CALLER_ADDR0 and CALLER_ADDR1. - * If from user mode there is only one stack frame on the stack, and - * accessing CALLER_ADDR1 will cause oops. So we need create a dummy - * stack frame to make trace_hardirqs_off happy. - * - * This is handy because we also need to save a bunch of GPRs, + * We save a bunch of GPRs, * r3 can be different from GPR3(r1) at this point, r9 and r11 * contains the old MSR and handler address respectively, * r4 & r5 can contain page fault arguments that need to be passed @@ -950,18 +945,11 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) */ andi. r10,r9,MSR_EE beq 1f - /* - * Since the ftrace irqsoff latency trace checks CALLER_ADDR1, - * which is the stack frame here, we need to force a stack frame - * in case we came from user space. - */ stwu r1,-32(r1) mflr r0 stw r0,4(r1) - stwu r1,-32(r1) bl trace_hardirqs_on - lwz r1,0(r1) - lwz r1,0(r1) + addi r1, r1, 32 lwz r9,_MSR(r1) 1: #endif /* CONFIG_TRACE_IRQFLAGS */ -- 2.13.3