Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1977030pxb; Fri, 22 Oct 2021 11:14:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfl02Yc2o0Fi3DToZpCKkme0YWUSmWOtWo+1VPiXIm677ffWraTHBl5M05Bd5aXDJCChxy X-Received: by 2002:a17:906:7017:: with SMTP id n23mr1337495ejj.446.1634926462289; Fri, 22 Oct 2021 11:14:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634926462; cv=none; d=google.com; s=arc-20160816; b=MQMs0MKi4b2W9sTKSgvEMIwgedzAypyOmPN0Wtav9efz7W6pM9R+xPnCh0JJA0q03g lNQy7BoDsOtwzZFarYlYQigV+E0fgVA60OPnKLpz7eGL7rmXrU24ebEJ/TQKZbR7n5f+ 2AmQfg1SGxmsC1WS1ukYmWSfZnwTzUG6T7GNskhUaDPV9U60N3uco7BlecfjOcVMq+Ff orLup9Sv6LDGticScyu0Tu7KN3deFjp/xQDZZ71jk+dWg8dk9z2z1g4g6YzGaqk3Gdxe vMdMJGoA8AtAl1ASsbw3B8ZXPr6LH1l98j1deYeyhZbGglZHKGpaamffTMxia+/gICMR DuDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=c8CtAzlMrRj/nIvMSfdCmX4811Z929+7RkLrnLQ6twQ=; b=w8KmgqsB81rt2qJCRLiWf+XiDPasMU5wVof0VbhQNuhFCt19CbJBeEQEWz5lSyDpMO QkWwV8mau6/e010oXIU991WK3DdEOC9lkKzaAcW46pCfyVm5e0Lf72psSHiE9+JVQitu MakoNR1kwUmSlWnYgqxGig0PSaKyNHDZMrX9KZPPLxbv4WkUMdtoBs4iNVoY+3CaDGjr iaafTnqZHg+Cdv0zPyrgjQeRXOa6iHQ89UMLXjqYdSH1KEFEtzdbN9i2Ly/9RcGGeoNe sYM3ylFPg0zsyNo0BQBKbGE6IUol2cvNGdmhKfkQL25Y1GhMJY2Ab448uHLmLqCjiNGJ BVBw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o26si925735edv.382.2021.10.22.11.13.57; Fri, 22 Oct 2021 11:14:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233678AbhJVSOU (ORCPT + 99 others); Fri, 22 Oct 2021 14:14:20 -0400 Received: from foss.arm.com ([217.140.110.172]:57458 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231472AbhJVSOS (ORCPT ); Fri, 22 Oct 2021 14:14:18 -0400 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 0A23B1063; Fri, 22 Oct 2021 11:12:00 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.73.6]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9D3023F73D; Fri, 22 Oct 2021 11:11:57 -0700 (PDT) Date: Fri, 22 Oct 2021 19:11:54 +0100 From: Mark Rutland To: madvenka@linux.microsoft.com Cc: broonie@kernel.org, jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v10 02/11] arm64: Make perf_callchain_kernel() use arch_stack_walk() Message-ID: <20211022181154.GM86184@C02TD0UTHF1T.local> References: <20211015025847.17694-1-madvenka@linux.microsoft.com> <20211015025847.17694-3-madvenka@linux.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211015025847.17694-3-madvenka@linux.microsoft.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 14, 2021 at 09:58:38PM -0500, madvenka@linux.microsoft.com wrote: > From: "Madhavan T. Venkataraman" > > Currently, perf_callchain_kernel() in ARM64 code walks the stack using > start_backtrace() and walk_stackframe(). Make it use arch_stack_walk() > instead. This makes maintenance easier. > > Signed-off-by: Madhavan T. Venkataraman This looks good to me; bailing out when perf_callchain_store() can't accept any more entries absolutely makes sense. I gave this a spin with: | # perf record -g -c1 ls | # perf report ... and the recorded callchains look sane. Reviewed-by: Mark Rutland Tested-by: Mark Rutland As mentioned on patch 1, I'd like to get this rebased atop Peter's untangling of ARCH_STACKWALK from STACKTRACE. Thanks, Mark. > --- > arch/arm64/kernel/perf_callchain.c | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/kernel/perf_callchain.c b/arch/arm64/kernel/perf_callchain.c > index 4a72c2727309..f173c448e852 100644 > --- a/arch/arm64/kernel/perf_callchain.c > +++ b/arch/arm64/kernel/perf_callchain.c > @@ -140,22 +140,18 @@ void perf_callchain_user(struct perf_callchain_entry_ctx *entry, > static bool callchain_trace(void *data, unsigned long pc) > { > struct perf_callchain_entry_ctx *entry = data; > - perf_callchain_store(entry, pc); > - return true; > + return perf_callchain_store(entry, pc) == 0; > } > > void perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, > struct pt_regs *regs) > { > - struct stackframe frame; > - > if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) { > /* We don't support guest os callchain now */ > return; > } > > - start_backtrace(&frame, regs->regs[29], regs->pc); > - walk_stackframe(current, &frame, callchain_trace, entry); > + arch_stack_walk(callchain_trace, entry, current, regs); > } > > unsigned long perf_instruction_pointer(struct pt_regs *regs) > -- > 2.25.1 >