From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Ross Lagerwall <ross.lagerwall@citrix.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>,
Bertrand Marquis <bertrand.marquis@arm.com>,
Michal Orzel <michal.orzel@amd.com>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/livepatch: fixup relocations to replaced symbols
Date: Tue, 22 Jul 2025 17:02:58 +0200 [thread overview]
Message-ID: <aH-oIqnKwEv3p6Hl@macbook.local> (raw)
In-Reply-To: <4bffb6b1-ebe7-444f-905d-092e69a2d8ef@suse.com>
On Wed, Jul 16, 2025 at 06:31:03PM +0200, Jan Beulich wrote:
> On 16.07.2025 18:00, Roger Pau Monne wrote:
> > In a livepatch payload relocations will refer to included functions. If
> > that function happens to be a replacement for an existing Xen function, the
> > relocations on the livepatch payload will use the newly introduced symbol,
> > rather than the old one. This is usually fine, but if the result of the
> > relocation is stored for later use (for example in the domain struct),
> > usages of this address will lead to a page-fault once the livepatch is
> > reverted.
> >
> > Implement a second pass over relocations once the list of replaced
> > functions has been loaded, and fixup any references to replaced functions
> > to use the old symbol address instead of the new one. There are some
> > sections that must be special cased to continue using the new symbol
> > address, as those instances must reference the newly added livepatch
> > content (for example the alternative patch sites).
>
> This is what I was fearing, when you first mentioned the problem (and the
> plan) to me. What I don't see is why you do your fixing up regardless of
> relocation type. Relative relocations within the payload ought to be fine
> to not override? At which point some of the special casing may already no
> longer be necessary.
>
> (Later) Except that if code uses PC-relative addressing to determine a
> pointer to store into some struct, that'll appear as a relative relocation
> type, too. But then you may have a bigger problem: When referencing and
> referenced code are in the same section and in the same translation unit,
> the assembler could avoid emitting a relocation altogether. You would see
> nothing to fix up ...
The only way for the referencing and referenced code to be in the same
function would be for the function to reference itself, which should
be quite rare? I don't recall seeing any code in Xen where a function
stores a pointer to itself.
Otherwise each function is in a separate section, and hence references
to functions should always use a relocation.
Thanks, Roger.
next prev parent reply other threads:[~2025-07-22 15:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-16 16:00 [PATCH] xen/livepatch: fixup relocations to replaced symbols Roger Pau Monne
2025-07-16 16:31 ` Jan Beulich
2025-07-22 15:02 ` Roger Pau Monné [this message]
2025-07-22 15:56 ` Jan Beulich
2025-07-21 15:51 ` Ross Lagerwall
2025-07-21 15:58 ` Jan Beulich
2025-07-22 15:30 ` Roger Pau Monné
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=aH-oIqnKwEv3p6Hl@macbook.local \
--to=roger.pau@citrix.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=bertrand.marquis@arm.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=ross.lagerwall@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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.