Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp1707215ybb; Fri, 29 Mar 2019 09:39:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqxKWAPL6mgODByvKDQHNPeJq6opt4fKlcySZ9Tt7I34DR+qDiFIscjBRA2kMv3zu38YJUS/ X-Received: by 2002:a17:902:822:: with SMTP id 31mr6340560plk.290.1553877592961; Fri, 29 Mar 2019 09:39:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553877592; cv=none; d=google.com; s=arc-20160816; b=CRU03hOTrUof5WBvJSizxCylBk+CZpcJQG1OEEzJJZMxo0AIS1pz8iA/2/4JAaDKAl pbRW9ivGcUiy7al16CFKbOWxOi4zAAgihOSUuB1fiKpt0+u3LuCnDNiK93JHJAOEOhjb n7TrKMgfKY17NT3/b9lb2pQ9oZoKnZvbm7DjK1Wv0fNbIFsQjVDnKNaK6VN04xIHc7QG t1mHNUWoYwyxIKRUyYCSqLCBwjL2+Fpf/glnNkUc+D6gBxhGDxEPZPfXM1yRWqJ0giji aHav+VSUbSaTkAHdWAVTS+sFu7gcVuqgWCHlJ6Ne+C2OKwpO3YOAYdcibcw74Rm/8iKj cnuQ== 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=hEmTQ9o0T7UyWMxVbi3/Eu5O/W8AzX4iVyLZHLLlYzg=; b=YItP9tZumnBFwyjESjACtGu77MjKtZv7hqnsb+m/4rxdBKJRaWh7MVXs7OK6Np4JAL SZpRa3Ar/V4vipWlr4J4tB6rVfxpJJE36nyvapPtimkWhPIoD6EeRHViXHgCWlSFv9VG jVMSC1MjX6WNZMU9nUWDC716b6/WYNelbEM8pNdI/P70J3UUodDoQH+X9p3ASZYZjWWq hiYo75zGZR+uQrUN1sPx6qSidgJyIhwoTkoB5Y9+OUv1QoholP5e+5KR8gJzJTV08PWO buJeS6W3MCsXXQ7McJIfjj6wG08xrlH8Fh0gLa/AkVXGejuNnNOCk6iS+uiZ4EwQ8upF To9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@c-s.fr header.s=mail header.b=X75PS0go; 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 p187si2245041pfp.89.2019.03.29.09.39.37; Fri, 29 Mar 2019 09:39:52 -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=X75PS0go; 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 S1729929AbfC2Qip (ORCPT + 99 others); Fri, 29 Mar 2019 12:38:45 -0400 Received: from pegase1.c-s.fr ([93.17.236.30]:54532 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729852AbfC2Qim (ORCPT ); Fri, 29 Mar 2019 12:38:42 -0400 Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 44W6qy4VTDz9tyQh; Fri, 29 Mar 2019 17:38:38 +0100 (CET) Authentication-Results: localhost; dkim=pass reason="1024-bit key; insecure key" header.d=c-s.fr header.i=@c-s.fr header.b=X75PS0go; 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 es42c00ocNvf; Fri, 29 Mar 2019 17:38:38 +0100 (CET) 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 44W6qy3Ns9z9tyQR; Fri, 29 Mar 2019 17:38:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c-s.fr; s=mail; t=1553877518; bh=hEmTQ9o0T7UyWMxVbi3/Eu5O/W8AzX4iVyLZHLLlYzg=; h=In-Reply-To:References:From:Subject:To:Cc:Date:From; b=X75PS0gojQfhh4QhIHdH0oAeU9z7Hb+RmNBQMPQ6kg0QpAli+N1LBxcpKArIKL7q8 Ed4cPAR9oJO6heTCf9/FulWpZotzCpUW4H7l0lJ8RvZN9X+rxM8vsPnWwtN9bdsi/a 0Jskt9DKYM5yAbbsGj+UAn/x250c2UQEpwW6mziU= Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 1224E8B93D; Fri, 29 Mar 2019 17:38:40 +0100 (CET) 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 bYi_-NeMyelb; Fri, 29 Mar 2019 17:38:40 +0100 (CET) Received: from po16846vm.idsi0.si.c-s.fr (po15451.idsi0.si.c-s.fr [172.25.231.2]) by messagerie.si.c-s.fr (Postfix) with ESMTP id E9C7A8B938; Fri, 29 Mar 2019 17:38:39 +0100 (CET) Received: by po16846vm.idsi0.si.c-s.fr (Postfix, from userid 0) id C93A76FC56; Fri, 29 Mar 2019 16:38:39 +0000 (UTC) Message-Id: <8f513e30d3fc875263befdaf38f4f80c3165c671.1553877076.git.christophe.leroy@c-s.fr> In-Reply-To: References: From: Christophe Leroy Subject: [PATCH v2 17/17] 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: Fri, 29 Mar 2019 16:38:39 +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 c648b75f41a3..c1e9be5cba10 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -237,12 +237,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 @@ -933,18 +928,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