From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A14EE3126CA for ; Tue, 10 Mar 2026 15:20:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773156038; cv=none; b=BD75wuemTJM70PULyffUWTzORCi+C+d7Znd112smmW7Zo72eXluNifHAgSjiXod+YfhMvsmB+OAl/jKjBq9W+Ue3xoO1e/skr+utVbvBSw8FudafOab5yH0I4GJvQrqy3QJru1ERm8/ErEX1b3FVW80F5TATs+1Hzp2whWMV4Y8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773156038; c=relaxed/simple; bh=SYZPVJ10Kwp6XnWS5i6rBpPqQl0W9tJjyaomlFn7Qtg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sa8I/Z7V2KVmy24DO/XC1Z1dnHk3x6/RjJ88U5l9rR6I/aBvGD9Mu7cDjLPcjZPvXh074xKwxYtXt3sNx8TMMnfV3i9MONAfLM9AKe1IWIpX9206kE31cBI8/clEb1dO1ZS7zfgG9xZG5hQgNXzQ7sEO4ljmerVZSDnlTCSS5r0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=fu5+DH4v; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="fu5+DH4v" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-439cb5af25bso3242221f8f.1 for ; Tue, 10 Mar 2026 08:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773156035; x=1773760835; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=L2/koJdZK95rU0leujZRvjliJH2foHXtNc8nZYKdbVs=; b=fu5+DH4vdS5//oTEXY5n42LxB6JFULdB9TnqKe2hiAN3MCIp3QD3XBH2MPwTYGpBtL ZLUqOO4RwGX1Io8C42RUAJbFo4YpF5CVl6izWTXZPzsw0x0UHSzCmyVm+YNnDT2KpnsL gxFx8i54q7qjPTSViVAnWNR6FcTP0sx6zMX3UA8y/qa4LNnP1EWfTDbCGeO7q46zNU4l PU0y9gLIntkPPkovTH74JM29GdJahk7p7SE0JN/scj1yHdIaLbbPdrgNyNgxuGjF/U5q MFGm8D7IjSut3qaLBre7JjPzMD8DPbnLDna/P2j+cPTc0tbGaOySUZZ93c+civQpXDRa xuTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773156035; x=1773760835; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=L2/koJdZK95rU0leujZRvjliJH2foHXtNc8nZYKdbVs=; b=IRGK0bWc9hTH8YjC9pBIePXC4SQSLIkSt3r6u8HU8ctc+MEGUQyZwAnWi7j9edAn7n ZvFuWolF4FONFNZuSSgtBvL0xQqkOpx2OO0VmiGNATheM3mOfSe6z0xsnd0bRPGEqdJK 6wt9M161DD+M2UOxgbqo7nzaoUrrRBuR+EiKIRwybf6K2jdw/pQEky3/cs8u8WtWu5GE 3sdAQz5V6qZkpLgFYxrTzXYuEO16nYRQZhC/6WkjLE+zCJVDZNmBey9wSlz4ZcIEFf9K z8DUjayeH7miGLNB/QQ9CxAYGFGyyom5eqt0KBhu9llaLcbruKDvy2aNJSasWLZGX0B/ VhfQ== X-Forwarded-Encrypted: i=1; AJvYcCXUGAJexSR+1b6m5unjYtaWrAZXr4nQieedsTfs69deZiNoFDORMxZmhgbnsgeQaVqagIZqz8NIhL2eMYU=@vger.kernel.org X-Gm-Message-State: AOJu0YxFoeorzbWZx/dAAakRX9gidWh3KFvp3gwQmXI9H5WtHpwXz7/u /EtMmWgdpoOyvG+2qhTD7xDypi5ekrYg9nSFxYtNLEp9XzKhF+hUL4i9ZL7r/ufeGqs= X-Gm-Gg: ATEYQzxeY8GDL4jJo+ruSvkuRuZro2gMPPl5oLz6VyCyoUAVNNv7lNoBXwXwKpDyVbE cLlVTXrKuDp0jrqiA1zpL2AvudX56UNlkV95XNmZs5kG1r9Lefx7zs7E91QwTFQrBZtYgd46xm6 YXAoD9MClkQQJQzAL03aThJ9qALZt5RRdHxjbsP/I1g3OfECfQPjf4lceQoExVSpXquMewPbS+o SGtjfu9wNHDTcSYmBvKMk7UFm+mZSZM/u+Lc/zk7oVBpa/7lZ279An5p+I8m+qALVmY2CWf2oU0 wh9CR2DiBn2QgpjdembYyHLrsPKAc7IIZyw02FtlbcQ9GvQz59vU5aL+5UamyRnYFpMb61vTH55 oG691e2JxkPXDHUPVb1QEP5mSmNqCtaNV3Qy4m74FIJjxxcRRBZb9y5xyh9IPcs7E8FLH/s0CQr UbPLmgaalD3fP0NmppC3lyPpPrsg== X-Received: by 2002:a05:6000:2505:b0:439:b26a:216f with SMTP id ffacd0b85a97d-439da87c0bdmr28137929f8f.56.1773156034926; Tue, 10 Mar 2026 08:20:34 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dad97abasm33722231f8f.10.2026.03.10.08.20.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 08:20:34 -0700 (PDT) Date: Tue, 10 Mar 2026 16:20:32 +0100 From: Petr Mladek To: 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 , 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 Subject: Re: [PATCH 1/3] kallsyms: embed source file:line info in kernel stack traces Message-ID: References: <20260303182103.3523438-1-sashal@kernel.org> <20260303182103.3523438-2-sashal@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 Fri 2026-03-06 12:14:45, Sasha Levin wrote: > On Fri, Mar 06, 2026 at 05:36:36PM +0100, Petr Mladek wrote: > > On Tue 2026-03-03 13:21:01, 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: > > > > > > --- a/include/linux/kallsyms.h > > > +++ b/include/linux/kallsyms.h > > > @@ -16,10 +16,19 @@ > > > #include > > > > > > #define KSYM_NAME_LEN 512 > > > + > > > +#ifdef CONFIG_KALLSYMS_LINEINFO > > > +/* Extra space for " (path/to/file.c:12345)" suffix */ > > > +#define KSYM_LINEINFO_LEN 128 > > > +#else > > > +#define KSYM_LINEINFO_LEN 0 > > > +#endif > > > + > > > #define KSYM_SYMBOL_LEN (sizeof("%s+%#lx/%#lx [%s %s]") + \ > > > > I guess that this is used also in ftrace where there formatting > > is delayed. We might want: > > > > #define KSYM_SYMBOL_LEN (sizeof("%s+%#lx/%#lx [%s %s] (%s:%u)") + \ > > KSYM_LINEINFO_LEN already covers the full expansion of the path and line > number, not just the literal format characters. ftrace stores raw addresses and > formats via %pS at print time into a KSYM_SYMBOL_LEN-sized buffer, so there > shouldn't be an issue here. I was curious why the sizeof("%s+%#lx/%#lx [%s %s]") was there. It did not make much sense to count some "random" part of the format string. I expected that it was related to the ftrace delayed formatting. But they are written to the tracing buffer, see trace_vbprintk(). But I believe that it does not need to be counted. It seems to be some cargo-cult programming. The size has been counted first by the commit d069cf94ca296b7fb ("kallsyms for new modules") back in v2.6.12-rc2, see https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=d069cf94ca296b7fb4c7e362e8f27e2c8aca70f1 And it seems that it was not needed there. That said, we could not simply remove it witout revisiting the rest of the computation. Especilly, we need to make sure that it counts all extra characters, like spaces, brackets, and the trailing '\0'. Ideally, we should replace the unsafe sprintf() with snprintf() in all users. (>> TODO ;-) > > > (KSYM_NAME_LEN - 1) + \ > > > 2*(BITS_PER_LONG*3/10) + (MODULE_NAME_LEN - 1) + \ > > > - (BUILD_ID_SIZE_MAX * 2) + 1) > > > + (BUILD_ID_SIZE_MAX * 2) + 1 + \ > > > + KSYM_LINEINFO_LEN) > > > > > > struct cred; > > > struct module; Best Regards, Petr