All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <hca@linux.ibm.com>
To: Philipp Rudo <prudo@redhat.com>
Cc: Alexander Egorenkov <egorenar@linux.ibm.com>,
	ltao@redhat.com, linux-s390@vger.kernel.org
Subject: Re: [PATCH v2 1/1] s390/kexec: handle R_390_PLT32DBL rela in arch_kexec_apply_relocations_add()
Date: Thu, 9 Dec 2021 12:15:59 +0100	[thread overview]
Message-ID: <YbHlb2YTjVzDqoTe@osiris> (raw)
In-Reply-To: <20211209120142.60642497@rhtmp>

On Thu, Dec 09, 2021 at 12:01:42PM +0100, Philipp Rudo wrote:
> On Thu,  9 Dec 2021 08:38:17 +0100
> Alexander Egorenkov <egorenar@linux.ibm.com> wrote:
> 
> > Starting with gcc 11.3, the C compiler will generate PLT-relative function
> > calls even if they are local and do not require it. Later on during linking,
> > the linker will replace all PLT-relative calls to local functions with
> > PC-relative ones. Unfortunately, the purgatory code of kexec/kdump is
> > not being linked as a regular executable or shared library would have been,
> > and therefore, all PLT-relative addresses remain in the generated purgatory
> > object code unresolved. This leads to the situation where the purgatory
> > code is being executed during kdump with all PLT-relative addresses
> > unresolved. And this results in endless loops within the purgatory code.
> > 
> > Furthermore, the clang C compiler has always behaved like described above
> > and this commit should fix kdump for kernels built with the latter.
> > 
> > Because the purgatory code is no regular executable or shared library,
> > contains only calls to local functions and has no PLT, all R_390_PLT32DBL
> > relocation entries can be resolved just like a R_390_PC32DBL one.
...
> > Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
> > Reported-by: Tao Liu <ltao@redhat.com>
> > Suggested-by: Philipp Rudo <prudo@redhat.com>
> 
> Thanks!
> 
> Reviewed-by: Philipp Rudo <prudo@redhat.com>

Applied, thanks!

      reply	other threads:[~2021-12-09 11:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09  7:38 [PATCH v2 1/1] s390/kexec: handle R_390_PLT32DBL rela in arch_kexec_apply_relocations_add() Alexander Egorenkov
2021-12-09 11:01 ` Philipp Rudo
2021-12-09 11:15   ` Heiko Carstens [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YbHlb2YTjVzDqoTe@osiris \
    --to=hca@linux.ibm.com \
    --cc=egorenar@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=ltao@redhat.com \
    --cc=prudo@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.