From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 1C80E17C69; Fri, 6 Mar 2026 05:31:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772775108; cv=none; b=jdZwWK2jCpgemMX0hfAvsEvuKcEkL4jmPkmZe6uAC9mRMSzh5zLEmNraJfJ0IzEhgmEU6pSydB+DUyaEd9cRCrv3ufikeQiou0f4kfwthAgeuTjz1AAzyp0CVFGNuWNiHOUAgYB/cNiWtQ0RAi/W5WbPMKPckdt7B/bvKSrh7A0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772775108; c=relaxed/simple; bh=TuZ4HMuvMsyaE+P8oAO3m10hFVVxMOdkXaWq3jt0wrA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=X+TrwMTrbHRj5OdxnSms5JAVrhmkqtZIWaaNDDPfzb9mfuEOniP0xiA+gD2yMVpg+XGAxpVIwoWx8HmsGGy8ugcdjOdK2lJYSI8IvTGDFMJ4svZcLcLCHfRgWf45ESNDkO1/E/4UZ9oTys/yD0EgUoTZ69lreSC7K4pZDjW7QLA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=NEifPV4A; arc=none smtp.client-ip=198.137.202.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="NEifPV4A" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Sender:Reply-To:Content-ID:Content-Description; bh=YTy9WH4252KkEisoIowgga7hEsIxg8Hn2L4+MHnhZgw=; b=NEifPV4AurNeboy+GzmVzpJVHk pwctB56sgrisw4DR+3m59BGRuE3/eH2ucib1ru2Foeoyijws5jEGElOGUzEPvtPclmrZ99bf5qths a1IWjYqYaNWxitOcK1mvNEi88gIiIj9SvUkXvpZDHmWl/mAmiXLamVGOuXYH0bWlocnbVVPjbJ6Zy locXi+7Kl9zKNKwfvkW31VzCNF+9fvduS54pqYATipwVQvgCATggLs94JIlg/393ipmtYYj+DTSIA 3xnED0N2OWbE+I74sUHAzeKsWY255E2+PuX1zxiXGzbSZ8kf2Erk9ZoFzKjvCJ+BuRDwC2ea7UY9Q eBt0H2Uw==; Received: from [50.53.43.113] (helo=[192.168.254.34]) by bombadil.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vyNml-000000032wP-2vq8; Fri, 06 Mar 2026 05:31:39 +0000 Message-ID: <14977e29-cd76-424c-89c3-9f8c73186e27@infradead.org> Date: Thu, 5 Mar 2026 21:31:38 -0800 Precedence: bulk X-Mailing-List: linux-modules@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] kallsyms: embed source file:line info in kernel stack traces To: Helge Deller , Sasha Levin Cc: Andrew Morton , Masahiro Yamada , Luis Chamberlain , Linus Torvalds , Richard Weinberger , Juergen Gross , Geert Uytterhoeven , James Bottomley , Jonathan Corbet , Nathan Chancellor , Nicolas Schier , Petr Pavlu , Daniel Gomez , Greg KH , Petr Mladek , Steven Rostedt , Kees Cook , Peter Zijlstra , Thorsten Leemhuis , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-modules@vger.kernel.org, linux-doc@vger.kernel.org References: <20260303182103.3523438-1-sashal@kernel.org> <20260303182103.3523438-2-sashal@kernel.org> <258d7167-2e82-4402-9545-108c501ae69e@gmx.de> Content-Language: en-US From: Randy Dunlap In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 3/5/26 2:26 PM, Helge Deller wrote: > On 3/5/26 03:18, Sasha Levin wrote: >> On Wed, Mar 04, 2026 at 09:17:37PM +0100, Helge Deller wrote: >>> On 3/3/26 19:21, Sasha Levin wrote: >>>> Add CONFIG_KALLSYMS_LINEINFO, which embeds a compact address-to-line >>>> lookup table in the kernel image so stack traces directly print source >>>> file and line number information: >>>> >>>>   root@localhost:~# echo c > /proc/sysrq-trigger >>>>   [   11.201987] sysrq: Trigger a crash >>>>   [   11.202831] Kernel panic - not syncing: sysrq triggered crash >>>>   [   11.206218] Call Trace: >>>>   [   11.206501]  >>>>   [   11.206749]  dump_stack_lvl+0x5d/0x80 (lib/dump_stack.c:94) >>>>   [   11.207403]  vpanic+0x36e/0x620 (kernel/panic.c:650) >>>>   [   11.208565]  ? __lock_acquire+0x465/0x2240 (kernel/locking/lockdep.c:4674) >>>>   [   11.209324]  panic+0xc9/0xd0 (kernel/panic.c:787) >>>>   [   11.211873]  ? find_held_lock+0x2b/0x80 (kernel/locking/lockdep.c:5350) >>>>   [   11.212597]  ? lock_release+0xd3/0x300 (kernel/locking/lockdep.c:5535) >>>>   [   11.213312]  sysrq_handle_crash+0x1a/0x20 (drivers/tty/sysrq.c:154) >>>>   [   11.214005]  __handle_sysrq.cold+0x66/0x256 (drivers/tty/sysrq.c:611) >>>>   [   11.214712]  write_sysrq_trigger+0x65/0x80 (drivers/tty/sysrq.c:1221) >>>>   [   11.215424]  proc_reg_write+0x1bd/0x3c0 (fs/proc/inode.c:330) >>>>   [   11.216061]  vfs_write+0x1c6/0xff0 (fs/read_write.c:686) >>>>   [   11.218848]  ksys_write+0xfa/0x200 (fs/read_write.c:740) >>>>   [   11.222394]  do_syscall_64+0xf3/0x690 (arch/x86/entry/syscall_64.c:63) >>>>   [   11.223942]  entry_SYSCALL_64_after_hwframe+0x77/0x7f (arch/x86/entry/entry_64.S:121) >>> >>> As mentioned in the other series, I really like this patch series. >>> >>> I tested this series again on the parisc architecture, and the relative >>> directories are now stripped with this version of your patch. >>> IIRC, the previous patch did show the subdirectory names. >>> [  132.840382] Backtrace: >>> [  132.840382]  [<104254d8>] show_stack+0x50/0x64 (traps.c:212) >>> [  132.840382]  [<1041c0c8>] dump_stack_lvl+0x6c/0xa0 (dump_stack.c:122) >>> [  132.840382]  [<1041c118>] dump_stack+0x1c/0x2c (dump_stack.c:130) >>> [  132.840382]  [<10402218>] vpanic+0x154/0x344 (panic.c:550) >>> [  132.840382]  [<10402438>] panic+0x30/0x34 (panic.c:787) >>> [  132.840382]  [<10bebea8>] sysrq_handle_crash+0x30/0x34 (rcupdate.h:110) >>> [  132.840382]  [<10bec720>] __handle_sysrq+0xc0/0x1e4 (preempt.h:14) >> >> Ugh... Can you confirm that you've build this kernel with O=? > > Yes. Both -Os and -O2 do not show the relative path. Helge, I'm fairly sure that Sasha meant with O=build_dir_name, not -O for optimization levels. >> The RFC had a dirty dirty hack around how we turn these absolute paths into >> relative ones, but I tried to re-do it so no one would yell at me :) > > Seems it is needed... > > Helge > -- ~Randy