[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220818133918.1112657-1-alexandr.lobakin@intel.com>
Date: Thu, 18 Aug 2022 15:39:18 +0200
From: Alexander Lobakin <alexandr.lobakin@...el.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Alexander Lobakin <alexandr.lobakin@...el.com>,
linux-kernel@...r.kernel.org,
Masahiro Yamada <masahiroy@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>,
"Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Masami Hiramatsu <mhiramat@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Jiri Kosina <jikos@...nel.org>,
Miroslav Benes <mbenes@...e.cz>,
Petr Mladek <pmladek@...e.com>,
Joe Lawrence <joe.lawrence@...hat.com>,
linux-kbuild@...r.kernel.org, live-patching@...r.kernel.org,
lkp@...el.com, stable@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] kallsyms: add option to include relative filepaths into kallsyms
From: Greg KH <gregkh@...uxfoundation.org>
Date: Thu, 18 Aug 2022 14:20:06 +0200
> On Thu, Aug 18, 2022 at 01:53:03PM +0200, Alexander Lobakin wrote:
> > This is an early RFC to not rewrite stuff one more time later on if
> > the implementation is not acceptable or any major design changes are
> > required. For the TODO list, please scroll to the end.
> >
> > Make kallsyms independent of symbols positions in vmlinux (or module)
> > by including relative filepath in each symbol's kallsyms value. I.e.
> >
> > dev_gro_receive -> net/core/gro.c:dev_gro_receive
> >
> > For the implementation details, please look at the patch 3/3.
> > Patch 2/3 is just a stub, I plan to reuse kallsyms enhancement from
> > the Rust series for it.
> > Patch 1/3 is a fix of one modpost macro straight from 2.6.12-rc2.
> >
> > A nice side effect is that it's now easier to debug the kernel, as
> > stacktraces will now tell every call's place in the file tree:
>
> That's a side effect, but that does not explain _why_ you want this
> change.
>
> What is this good for? Who can use it? Why is it worth added build
> times?
I think I wrote that we need to get rid of this positioned-based
search for kallsyms, at least for livepatching and probes, didn't
I?
OTOH I didn't write that originally that was a prereq for FG-KASLR,
but then I decided it deserves a separate series =\ Thanks for
mentioning this, so I wrote it here now and will not forget this
time to mention it in the cover letter for v2.
>
> You don't tell us anything except what this does :(
>
> thanks,
>
> greg k-h
Thanks,
Olek
Powered by blists - more mailing lists