Received: by 2002:a19:f614:0:0:0:0:0 with SMTP id x20csp22713lfe; Fri, 15 Apr 2022 17:37:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwuoH6O9C1t6rlfD5aQiF0578WIWQ2lAMGUFUpeoTN02rHDDwql2Vb7dAJInN8muUfaxxjr X-Received: by 2002:a17:903:41ca:b0:158:7f07:e7bc with SMTP id u10-20020a17090341ca00b001587f07e7bcmr1308665ple.32.1650069431277; Fri, 15 Apr 2022 17:37:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650069431; cv=none; d=google.com; s=arc-20160816; b=wPzyJC+89Cmrr+a3iwgS/5qgp1qAyjYJtPfbMAhwJX6BsjHzoTDpVKH0AfiKQ+q4Wc zU5DBYVGGu0C7TIssP9nKhS0k4JtvXho2DR4ao30rbuIL47aSgk+LBgIvVPwyhyZfHxG jUl6/bD+B2DxqBdURTnPIs83USjZope8i/R3lb7opURdB3dnhXWvp+iDhS5gkV1Ayglx qlQtp2DCNump6kq/Z8Z2ambZll8maxV/m1B0O6/crUOTpJ0mDw7+WE15SI8vUvuS1V5k AiRFwgO3kIJQHu5yLJyIUFikW8NVknpygR4U3B2yk0nsM6X6+SEnsp2OQiV39CgfrBAa jsUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=NDIfDROhgP0wSLqE6oFoKUEcbdUubq4kGqQhkfIzBhI=; b=DNRXmPUzxQ/Af5mBTHBPenVtqTTFq3lpFyqfHoqib6/O5BEB8OwPgUcgSiPI4eUzvM n4UfoTN4Qmunf9jhMCTFpVqBPHV/jkDYFeAZuDSiPNlnRFZLHi26M6WB++ERIvl3bEBJ Ep+qDqEJf5dV3F34U8Q7Y7MaF4VYpecXIkpxq7hZ4IVInL03PyitaGXObY9xl20qbrcE D8L69VJJvl6ongmKizjy6GVnLn9wfFeGLCahcYxiFhIeKWhziA7dc+VHqeqKyOUIwJlf bEv78HE9E2ePmJjzhxylpebc7njUJT5++BmOMljQp7tbuZWKDuumIyPdM1NcaWwzP8qv yoEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=msy61rTz; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id j17-20020a056a00235100b0050608866df1si3090976pfj.109.2022.04.15.17.37.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 17:37:11 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=msy61rTz; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A6C95FA22F; Fri, 15 Apr 2022 17:32:40 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345177AbiDNNpU (ORCPT + 99 others); Thu, 14 Apr 2022 09:45:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245741AbiDNN3W (ORCPT ); Thu, 14 Apr 2022 09:29:22 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 949EBAFB00; Thu, 14 Apr 2022 06:24:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 589F7B82983; Thu, 14 Apr 2022 13:23:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2627C385A1; Thu, 14 Apr 2022 13:23:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649942638; bh=fmpcjlrQyuXeYIr4SD899N4DuouCEUXenDr/5r7lMkE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=msy61rTz/R5k4efNcT/LGdAuJoSKocM/L3Z2Oy3YMVftqR5bBEsBg8jlFmNMllvAV 0uCAa188l7khO9k2icbHEE2zPDR2ymsdchFIo+h1+va/78+YwTrjOhFrDDp9Jmp6Bt 8TuRBysfMUis6GjXLx02xuTZKXC2FV4oAzb0iKZw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ard Biesheuvel , "Steven Rostedt (Google)" , Sasha Levin Subject: [PATCH 4.19 208/338] ARM: ftrace: avoid redundant loads or clobbering IP Date: Thu, 14 Apr 2022 15:11:51 +0200 Message-Id: <20220414110844.817011928@linuxfoundation.org> X-Mailer: git-send-email 2.35.2 In-Reply-To: <20220414110838.883074566@linuxfoundation.org> References: <20220414110838.883074566@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ard Biesheuvel [ Upstream commit d11967870815b5ab89843980e35aab616c97c463 ] Tweak the ftrace return paths to avoid redundant loads of SP, as well as unnecessary clobbering of IP. This also fixes the inconsistency of using MOV to perform a function return, which is sub-optimal on recent micro-architectures but more importantly, does not perform an interworking return, unlike compiler generated function returns in Thumb2 builds. Let's fix this by popping PC from the stack like most ordinary code does. Signed-off-by: Ard Biesheuvel Reviewed-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin --- arch/arm/kernel/entry-ftrace.S | 51 +++++++++++++++------------------- 1 file changed, 22 insertions(+), 29 deletions(-) diff --git a/arch/arm/kernel/entry-ftrace.S b/arch/arm/kernel/entry-ftrace.S index 1acf4d05e94c..393c342ecd51 100644 --- a/arch/arm/kernel/entry-ftrace.S +++ b/arch/arm/kernel/entry-ftrace.S @@ -41,10 +41,7 @@ * mcount can be thought of as a function called in the middle of a subroutine * call. As such, it needs to be transparent for both the caller and the * callee: the original lr needs to be restored when leaving mcount, and no - * registers should be clobbered. (In the __gnu_mcount_nc implementation, we - * clobber the ip register. This is OK because the ARM calling convention - * allows it to be clobbered in subroutines and doesn't use it to hold - * parameters.) + * registers should be clobbered. * * When using dynamic ftrace, we patch out the mcount call by a "mov r0, r0" * for the mcount case, and a "pop {lr}" for the __gnu_mcount_nc case (see @@ -96,26 +93,25 @@ .macro __ftrace_regs_caller - sub sp, sp, #8 @ space for PC and CPSR OLD_R0, + str lr, [sp, #-8]! @ store LR as PC and make space for CPSR/OLD_R0, @ OLD_R0 will overwrite previous LR - add ip, sp, #12 @ move in IP the value of SP as it was - @ before the push {lr} of the mcount mechanism + ldr lr, [sp, #8] @ get previous LR - str lr, [sp, #0] @ store LR instead of PC + str r0, [sp, #8] @ write r0 as OLD_R0 over previous LR - ldr lr, [sp, #8] @ get previous LR + str lr, [sp, #-4]! @ store previous LR as LR - str r0, [sp, #8] @ write r0 as OLD_R0 over previous LR + add lr, sp, #16 @ move in LR the value of SP as it was + @ before the push {lr} of the mcount mechanism - stmdb sp!, {ip, lr} - stmdb sp!, {r0-r11, lr} + push {r0-r11, ip, lr} @ stack content at this point: @ 0 4 48 52 56 60 64 68 72 - @ R0 | R1 | ... | LR | SP + 4 | previous LR | LR | PSR | OLD_R0 | + @ R0 | R1 | ... | IP | SP + 4 | previous LR | LR | PSR | OLD_R0 | - mov r3, sp @ struct pt_regs* + mov r3, sp @ struct pt_regs* ldr r2, =function_trace_op ldr r2, [r2] @ pointer to the current @@ -138,11 +134,9 @@ ftrace_graph_regs_call: #endif @ pop saved regs - ldmia sp!, {r0-r12} @ restore r0 through r12 - ldr ip, [sp, #8] @ restore PC - ldr lr, [sp, #4] @ restore LR - ldr sp, [sp, #0] @ restore SP - mov pc, ip @ return + pop {r0-r11, ip, lr} @ restore r0 through r12 + ldr lr, [sp], #4 @ restore LR + ldr pc, [sp], #12 .endm #ifdef CONFIG_FUNCTION_GRAPH_TRACER @@ -158,11 +152,9 @@ ftrace_graph_regs_call: bl prepare_ftrace_return @ pop registers saved in ftrace_regs_caller - ldmia sp!, {r0-r12} @ restore r0 through r12 - ldr ip, [sp, #8] @ restore PC - ldr lr, [sp, #4] @ restore LR - ldr sp, [sp, #0] @ restore SP - mov pc, ip @ return + pop {r0-r11, ip, lr} @ restore r0 through r12 + ldr lr, [sp], #4 @ restore LR + ldr pc, [sp], #12 .endm #endif @@ -273,16 +265,17 @@ ENDPROC(ftrace_graph_caller_old) .endm .macro mcount_exit - ldmia sp!, {r0-r3, ip, lr} - ret ip + ldmia sp!, {r0-r3} + ldr lr, [sp, #4] + ldr pc, [sp], #8 .endm ENTRY(__gnu_mcount_nc) UNWIND(.fnstart) #ifdef CONFIG_DYNAMIC_FTRACE - mov ip, lr - ldmia sp!, {lr} - ret ip + push {lr} + ldr lr, [sp, #4] + ldr pc, [sp], #8 #else __mcount #endif -- 2.34.1