"Naveen N. Rao" writes:
> Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
> symbols") [1], binutils (v2.36+) started dropping section symbols that
> it thought were unused. This isn't an issue in general, but with
> kexec_file.c, gcc is placing kexec_arch_apply_relocations[_add]
Hi Eric,
On 05/18/22 at 04:59pm, Eric W. Biederman wrote:
> "Naveen N. Rao" writes:
>
> > Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
> > symbols") [1], binutils (v2.36+) started dropping section symbols that
> > it thought were unused. This isn't an issue in general, but w
On 05/18/22 at 01:29pm, Heiko Carstens wrote:
> On Thu, May 12, 2022 at 03:01:23PM +0800, Coiby Xu wrote:
> > From: Michal Suchanek
> >
> > commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
> > adds support for KEXEC_SIG verification with keys from platform keyring
> > but
Can I engage your services?
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
"Naveen N. Rao" writes:
> Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
> symbols") [1], binutils (v2.36+) started dropping section symbols that
> it thought were unused. This isn't an issue in general, but with
> kexec_file.c, gcc is placing kexec_arch_apply_relocations[_add]
On Wed, 18 May 2022 23:48:28 +0530 "Naveen N. Rao"
wrote:
> Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
> symbols") [1], binutils (v2.36+) started dropping section symbols that
> it thought were unused. This isn't an issue in general, but with
> kexec_file.c, gcc is placing
Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
symbols") [1], binutils (v2.36+) started dropping section symbols that
it thought were unused. This isn't an issue in general, but with
kexec_file.c, gcc is placing kexec_arch_apply_relocations[_add] into a
separate .text.unlikely se
Eric W. Biederman wrote:
Michael Ellerman writes:
"Eric W. Biederman" writes:
Looking at this the pr_err is absolutely needed. If an unsupported case
winds up in the purgatory blob and the code can't handle it things
will fail silently much worse later.
It won't fail later, it will fail t
On 18/05/2022 04:33, Petr Mladek wrote:
> [...]
> Anyway, I would distinguish it the following way.
>
> + If the notifier is preserving kernel log then it should be ideally
> treated as kmsg_dump().
>
> + It the notifier is saving another debugging data then it better
> fits into the
On 18/05/2022 04:58, Petr Mladek wrote:
> [...]
>> I does similar things like kmsg_dump() so it should be called in
>> the same location (after info notifier list and before kdump).
>>
>> A solution might be to put it at these notifiers at the very
>> end of the "info" list or make extra "dump" not
On 18/05/2022 04:38, Petr Mladek wrote:
> [...]
> I have answered this in more detail in the other reply, see
> https://lore.kernel.org/r/YoShZVYNAdvvjb7z@alley
>
> I agree that both notifiers in
>
> drivers/soc/bcm/brcmstb/pm/pm-arm.c
> drivers/firmware/google/gsmi.c
>
> better fit into
Michael Ellerman writes:
> "Eric W. Biederman" writes:
>> Looking at this the pr_err is absolutely needed. If an unsupported case
>> winds up in the purgatory blob and the code can't handle it things
>> will fail silently much worse later.
>
> It won't fail later, it will fail the syscall.
>
>
On Thu, May 12, 2022 at 03:01:23PM +0800, Coiby Xu wrote:
> From: Michal Suchanek
>
> commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
> adds support for KEXEC_SIG verification with keys from platform keyring
> but the built-in keys and secondary keyring are not used.
>
On 05/16/22 at 05:05pm, Stephen Brennan wrote:
> The kernel can be configured to contain a lot of introspection or
> debugging information built-in, such as ORC for unwinding stack traces,
> BTF for type information, and of course kallsyms. Debuggers could use
> this information to navigate a core
On 05/18/22 at 02:48pm, Naveen N. Rao wrote:
> Baoquan He wrote:
> > On 05/18/22 at 12:26pm, Michael Ellerman wrote:
> > >
> > > It seems that recordmcount is not really maintained anymore now that x86
> > > uses objtool?
> > >
> > > There've been several threads about fixing recordmcount, but no
Baoquan He wrote:
On 05/18/22 at 12:26pm, Michael Ellerman wrote:
It seems that recordmcount is not really maintained anymore now that x86
uses objtool?
There've been several threads about fixing recordmcount, but none of
them seem to have lead to a solution.
These weak symbol vs recordmcount
On 05/18/22 at 12:26pm, Michael Ellerman wrote:
> "Eric W. Biederman" writes:
> > Looking at this the pr_err is absolutely needed. If an unsupported case
> > winds up in the purgatory blob and the code can't handle it things
> > will fail silently much worse later.
>
> It won't fail later, it wi
17 matches
Mail list logo
