Received: by 2002:a05:7412:98c1:b0:fa:551:50a7 with SMTP id kc1csp1679130rdb; Mon, 8 Jan 2024 07:03:54 -0800 (PST) X-Google-Smtp-Source: AGHT+IFePBxxmeOBwfHiJ1WkkUgFJtEHvEoHcq9SKHQ644tUDPdbLmFBBlmqNs+Zml6ssljWQ1te X-Received: by 2002:a17:90b:1253:b0:28c:d8e5:6105 with SMTP id gx19-20020a17090b125300b0028cd8e56105mr1054185pjb.96.1704726233725; Mon, 08 Jan 2024 07:03:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704726233; cv=none; d=google.com; s=arc-20160816; b=Pz4WDoY/H51vkTeNuidwdCtsiBgp8xttfRqTpvWywtexCHXduhyVyiEVWswZ6idiy/ iyUGqH4hsg2o1qHCHdDKfApymM+TBmXgs3Pp9bbC/OPYDLioMsZ2sl/gOZyAid56Badx VJSFsxFC30//AD5epXmAM9iAVKKBj0Qqmy2P0TE5iFNjh6MM4bIi4Xegj0cK1yftax3W YBtG8GUlIjvzZoowFAdlDzsUZ1BhFfIVGOSDXQXaK0yKJZzEh/xh3avlEXRkXVRv7E65 0T26rsMp9Njovht7nT89iRwaJiRgVJg8x3GHmb64P+GASXKmtEDf7eF4pYIjFueRkgAB JQpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date; bh=IQJIFoD8okj0/fhWPcUYpkZOOq0JwYrGfvaKwA52FKQ=; fh=563vw1N0KzdI/CLOIL7m0Z0nGoOOeplg3/HMitEV324=; b=gNVEuChPHGtyZxZuDU+wPqbXUtErye+9fnOOGZt8Ht7hDa3NW+I7jh0UbQqnEznd2P //h6CkPszuAQBOcRDBqoSfQg4EZ+aChHButjNxz6n2Bu4wSOiMSrcNBaSBR5mcGfjN17 rZ9VLa4ymTGG3+reMBbMsTqb7jHAqh7vJec2WTSDXM7DqTVC/55pQKfmGo4fLFCQuoF0 06vkxYDHBX7QuHEFGNN+IQNq56lxiWFB7WpZBjXA5h4jSZDskrkE4tUJtgURgpVDAmVh GUfyZiVNNEN+ir9N95cJrPGLbgWW+rrrd8i8u6sVYpDyDGnQt/niCAg9L8Yn7DkXrEDa J+lw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-19733-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19733-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id i7-20020a17090a974700b0028cbd8d3293si5729361pjw.159.2024.01.08.07.03.53 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 07:03:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-19733-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-19733-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19733-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 66D84284489 for ; Mon, 8 Jan 2024 15:03:50 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1D64B4C3AD; Mon, 8 Jan 2024 15:03:31 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 44FCC47796; Mon, 8 Jan 2024 15:03:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5D034C15; Mon, 8 Jan 2024 07:04:13 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.89.149]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE35C3F64C; Mon, 8 Jan 2024 07:03:24 -0800 (PST) Date: Mon, 8 Jan 2024 15:03:21 +0000 From: Mark Rutland To: Masami Hiramatsu Cc: Alexei Starovoitov , Steven Rostedt , Florent Revest , linux-trace-kernel@vger.kernel.org, LKML , Martin KaFai Lau , bpf , Sven Schnelle , Alexei Starovoitov , Jiri Olsa , Arnaldo Carvalho de Melo , Daniel Borkmann , Alan Maguire , Peter Zijlstra , Thomas Gleixner , Guo Ren Subject: Re: [PATCH v5 11/34] function_graph: Have the instances use their own ftrace_ops for filtering Message-ID: References: <170290509018.220107.1347127510564358608.stgit@devnote2> <170290522555.220107.1435543481968270637.stgit@devnote2> <20240108101436.07509def635fbecf80a59ae6@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jan 08, 2024 at 02:21:03PM +0000, Mark Rutland wrote: > On Mon, Jan 08, 2024 at 12:25:55PM +0000, Mark Rutland wrote: > > We also have HAVE_FUNCTION_GRAPH_RET_ADDR_PTR, but since the return address is > > not on the stack at the point function-entry is intercepted we use the FP as > > the retp value -- in the absence of tail calls this will be different between a > > caller and callee. > > Ah; I just spotted that this patch changed that in ftrace_graph_func(), which > is the source of the bug. > > As of this patch, we use the address of fregs->lr as the retp value, but the > unwinder still uses the FP value, and so when unwind_recover_return_address() > calls ftrace_graph_ret_addr(), the retp value won't match the expected entry on > the fgraph ret_stack, resulting in failing to find the expected entry. > > Since the ftrace_regs only exist transiently during function entry/exit, it's > possible for a stackframe to reuse that same address on the stack, which would > result in finding a different entry by mistake. > > The diff below restores the existing behaviour and fixes the issue for me. > Could you please fold that into this patch? > > On a separate note, looking at how this patch changed arm64's > ftrace_graph_func(), do we need similar changes to arm64's > prepare_ftrace_return() for the old-style mcount based ftrace? > > Mark. > > ---->8---- > diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c > index 205937e04ece..329092ce06ba 100644 > --- a/arch/arm64/kernel/ftrace.c > +++ b/arch/arm64/kernel/ftrace.c > @@ -495,7 +495,7 @@ void ftrace_graph_func(unsigned long ip, unsigned long parent_ip, > if (bit < 0) > return; > > - if (!function_graph_enter_ops(*parent, ip, fregs->fp, parent, gops)) > + if (!function_graph_enter_ops(*parent, ip, fregs->fp, (void *)fregs->fp, gops)) > *parent = (unsigned long)&return_to_handler; > > ftrace_test_recursion_unlock(bit); Thinking some more, this line gets excessively long when we pass the fregs too, so it's probably worth adding a local variable for fp, i.e. the diff below. Mark. ---->8---- diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c index 205937e04ece..d4e142ef4686 100644 --- a/arch/arm64/kernel/ftrace.c +++ b/arch/arm64/kernel/ftrace.c @@ -481,8 +481,9 @@ void prepare_ftrace_return(unsigned long self_addr, unsigned long *parent, void ftrace_graph_func(unsigned long ip, unsigned long parent_ip, struct ftrace_ops *op, struct ftrace_regs *fregs) { - unsigned long *parent = &fregs->lr; struct fgraph_ops *gops = container_of(op, struct fgraph_ops, ops); + unsigned long *parent = &fregs->lr; + unsigned long fp = fregs->fp; int bit; if (unlikely(ftrace_graph_is_dead())) @@ -495,7 +496,7 @@ void ftrace_graph_func(unsigned long ip, unsigned long parent_ip, if (bit < 0) return; - if (!function_graph_enter_ops(*parent, ip, fregs->fp, parent, gops)) + if (!function_graph_enter_ops(*parent, ip, fp, (void *)fp, gops)) *parent = (unsigned long)&return_to_handler; ftrace_test_recursion_unlock(bit);