From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
Ross Lagerwall <ross.lagerwall@citrix.com>
Subject: Re: [PATCH v2 5/6] x86/alternatives: do not BUG during apply
Date: Wed, 25 Sep 2024 15:55:25 +0200 [thread overview]
Message-ID: <ZvQWTSr7o8V3UW6p@macbook.local> (raw)
In-Reply-To: <00ad838a-a086-4b18-a32e-0a4a6cd52fe4@citrix.com>
On Wed, Sep 25, 2024 at 11:53:30AM +0100, Andrew Cooper wrote:
> On 25/09/2024 9:42 am, Roger Pau Monne wrote:
> > alternatives is used both at boot time, and when loading livepatch payloads.
> > While for the former it makes sense to panic, it's not useful for the later, as
> > for livepatches it's possible to fail to load the livepatch if alternatives
> > cannot be resolved and continue operating normally.
> >
> > Relax the BUGs in _apply_alternatives() to instead return an error code. The
> > caller will figure out whether the failures are fatal and panic.
> >
> > Print an error message to provide some user-readable information about what
> > went wrong.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>
> Much nicer. A few more diagnostic comments.
>
> > diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
> > index 7824053c9d33..c8848ba6006e 100644
> > --- a/xen/arch/x86/alternative.c
> > +++ b/xen/arch/x86/alternative.c
> > @@ -198,9 +198,29 @@ static void init_or_livepatch _apply_alternatives(struct alt_instr *start,
> > uint8_t buf[MAX_PATCH_LEN];
> > unsigned int total_len = a->orig_len + a->pad_len;
> >
> > - BUG_ON(a->repl_len > total_len);
> > - BUG_ON(total_len > sizeof(buf));
> > - BUG_ON(a->cpuid >= NCAPINTS * 32);
> > + if ( a->repl_len > total_len )
> > + {
> > + printk(XENLOG_ERR
> > + "alt replacement size (%#x) bigger than destination (%#x)\n",
>
> These all say "some alternative went wrong", without identifying which.
> For x86_decode_lite(), debugging was far easier when using:
>
> "Alternative for %ps ...", ALT_ORIG_PTR(a)
>
> If we get the order of loading correct, then %ps will even work for a
> livepatch, but that's secondary - even the raw number is slightly useful
> given the livepatch load address.
I don't think this will work as-is for livepatches. The call to
register the virtual region is currently done in livepatch_upload(),
after load_payload_data() has completed.
We could see about registering the virtual region earlier (no
volunteering to do that work right now).
> I could be talked down to just "Alt for %ps" as you've got it here. I
> think it's clear enough in context. So, I'd recommend:
>
> "Alt for %ps, replacement size %#x larger than origin %#x\n".
>
> Here, I think origin is better than destination, when discussing
> alternatives.
Sure.
> I can adjust on commit. Everything else is fine.
If you are comfortable with doing the adjustments on commit, please go
ahead.
Thanks, Roger.
next prev parent reply other threads:[~2024-09-25 13:55 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 8:42 [PATCH v2 0/6] xen/livepatch: improvements to loading Roger Pau Monne
2024-09-25 8:42 ` [PATCH v2 1/6] xen/livepatch: remove useless check for duplicated sections Roger Pau Monne
2024-09-25 8:52 ` Jan Beulich
2024-09-25 9:21 ` Roger Pau Monné
2024-09-25 9:29 ` Andrew Cooper
2024-09-25 8:42 ` [PATCH v2 2/6] xen/livepatch: zero pointer to temporary load buffer Roger Pau Monne
2024-09-25 9:33 ` Andrew Cooper
2024-09-25 10:00 ` Roger Pau Monné
2024-09-25 18:28 ` Andrew Cooper
2024-09-26 7:06 ` Roger Pau Monné
2024-09-26 8:22 ` Roger Pau Monné
2024-09-26 8:24 ` Andrew Cooper
2024-09-26 8:36 ` Roger Pau Monné
2024-09-25 8:42 ` [PATCH v2 3/6] xen/livepatch: simplify and unify logic in prepare_payload() Roger Pau Monne
2024-09-25 9:37 ` Andrew Cooper
2024-09-25 10:02 ` Roger Pau Monné
2024-09-25 8:42 ` [PATCH v2 4/6] xen/livepatch: do Xen build-id check earlier Roger Pau Monne
2024-09-25 10:21 ` Andrew Cooper
2024-09-25 13:39 ` Roger Pau Monné
2024-09-25 8:42 ` [PATCH v2 5/6] x86/alternatives: do not BUG during apply Roger Pau Monne
2024-09-25 9:01 ` Jan Beulich
2024-09-25 9:28 ` Roger Pau Monné
2024-09-25 10:02 ` Jan Beulich
2024-09-25 10:25 ` Andrew Cooper
2024-09-25 10:53 ` Andrew Cooper
2024-09-25 13:55 ` Roger Pau Monné [this message]
2024-09-25 8:42 ` [PATCH v2 6/6] x86/alternative: build time check feature is in range Roger Pau Monne
2024-09-25 8:51 ` Andrew Cooper
2024-09-25 9:24 ` Roger Pau Monné
2024-09-25 9:04 ` Jan Beulich
2024-09-25 9:23 ` 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=ZvQWTSr7o8V3UW6p@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=ross.lagerwall@citrix.com \
--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.