From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE9253C279F for ; Thu, 5 Mar 2026 16:11:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772727076; cv=none; b=OGyaypK6j+FL9FDRq9Qq4KbMlGImvXClwlSW/KEKcFFghK1K64SAiM8dJ2FjwKuKpPnkbTrV+0QcWB8ezlkUZAEXkMvby8cJrv+hPc27p+Oq3PaYAKBWKasmi/btxKJ7x4obKSRdvYwbel9lizriOKkhfe1lypSyF0Ot+iphqyo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772727076; c=relaxed/simple; bh=CV3zEaCpU+GdTDsW0mqfraTzm8F8z7xCJz2QA3StXpA=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=fj2RgVwXTwlS1MxBMSkTXGXalBjCAGcWU92US85vMjZz4QkDWCAb9IKBOS6Tn8BSv62pZHDfhSk5P/+Nl9Xqx6+cKYUUeuUgCu7KEJqvXQlw5APcjNDKO1vIJsw6I1n5cbkjw7qZzLeEc8w93C3ETATuHIr02K6w5MUq9lS2dW4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qXq1wVUY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qXq1wVUY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 894C5C116C6; Thu, 5 Mar 2026 16:11:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772727076; bh=CV3zEaCpU+GdTDsW0mqfraTzm8F8z7xCJz2QA3StXpA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qXq1wVUYLIxT7MMSLyffiorOh1G3EDlpmF9is1O69vpLK4vyPCh2QY7XN6QFf4VQZ TtvMSxHo38/it9XaPrdaSmu75D7D+r0oXdzfct6zc0r2bXJrL5BJrastsgf191TL7x XzCRk+jCyClZCKac3IB2Q5012EY+LYEFdEzx7/db6IOrxWqPMyIg3/IKkXNCblr1x3 91JNDDWblYaCl4hLLulZRFF5pZgOaraqNRJzZlH4XTz5H+xcO+isky1ze7djMJRofl HNRiVKFPJ6GEa8USWj5CIBbuuSMvl5Oi7ufZuez6vMWzGpvcPhBhyhXJ5hJ+KxTKpH CxFZi7v6wuo0w== Date: Fri, 6 Mar 2026 01:11:12 +0900 From: Masami Hiramatsu (Google) To: Matthieu Baerts Cc: Andrew Morton , Sasha Levin , Carlos Llamas , Luca Ceresoli , linux-kernel@vger.kernel.org Subject: Re: [PATCH] decode_stacktrace: Support heuristic caller address search Message-Id: <20260306011112.6f05f1431740e6dd09cb4dee@kernel.org> In-Reply-To: <23aaa915-08b4-4f9d-9622-6ee7f770c8be@kernel.org> References: <177268753893.3271988.11559821020066428486.stgit@mhiramat.tok.corp.google.com> <23aaa915-08b4-4f9d-9622-6ee7f770c8be@kernel.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Thu, 5 Mar 2026 15:56:13 +0100 Matthieu Baerts wrote: > Hi Masami, > > On 05/03/2026 06:12, Masami Hiramatsu (Google) wrote: > > From: Masami Hiramatsu (Google) > > > > Add -c option to search call address search to decode_stacktrace. > > This tries to decode line info backwards, starting from 1byte before > > the return address, and displays the first line info it founds as > > the caller address. > > If it tries up to 10bytes before (or the symbol address) and still > > can not find it, it gives up and decodes the return address. > > Thank you for this new option! > > > With -c option: > > Call Trace: > > > > dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) > > lockdep_rcu_suspicious (kernel/locking/lockdep.c:6876) > > event_filter_pid_sched_process_fork (kernel/trace/trace_events.c:1057) > > kernel_clone (include/trace/events/sched.h:396 include/trace/events/sched.h:396 kernel/fork.c:2664) > > __x64_sys_clone (kernel/fork.c:2795 kernel/fork.c:2779 kernel/fork.c:2779) > > do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) > > ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) > > ? trace_irq_disable (include/trace/events/preemptirq.h:36) > > entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) > > > > > > Without -c option: > > Call Trace: > > > > dump_stack_lvl (lib/dump_stack.c:122) > > lockdep_rcu_suspicious (kernel/locking/lockdep.c:6877) > > event_filter_pid_sched_process_fork (kernel/trace/trace_events.c:?) > > kernel_clone (include/trace/events/sched.h:? include/trace/events/sched.h:396 kernel/fork.c:2664) > > __x64_sys_clone (kernel/fork.c:2779) > > do_syscall_64 (arch/x86/entry/syscall_64.c:?) > > ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) > > ? trace_irq_disable (include/trace/events/preemptirq.h:36) > > entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) > That's better indeed! > > Do we need a new option for that? Could it not be the new default > behaviour? Or are there any downsides with it? AFAIK, this may not work well on the architectures which have delay slot (I have not tested) which will execute one more instruction after branch before branching. In that case, the return address will not be the next instruction of the delay slot. But I think that is not popular anymore, so we can switch the default behavior and maybe we can switch it based on architecture. Thank you, > > "addr2line" will be called more, but if it is worth it, it is probably > not an issue, or is it? > > Cheers, > Matt > -- > Sponsored by the NGI0 Core fund. > -- Masami Hiramatsu (Google)