Re: [PATCH 2/2] x86/xen: fix memblock_reserve() usage on PVH

[Jürgen Groß <jgross@xxxxxxxx>]

On 25.07.24 10:10, Roger Pau Monné wrote:
> On Thu, Jul 25, 2024 at 10:01:17AM +0200, Jürgen Groß wrote:
> > On 25.07.24 09:31, Roger Pau Monne wrote:
> > > The current usage of memblock_reserve() in init_pvh_bootparams() is done before
> > > the .bss is zeroed, and that used to be fine when
> > > memblock_reserved_init_regions implicitly ended up in the .meminit.data
> > > section.  However after commit 73db3abdca58c memblock_reserved_init_regions
> > > ends up in the .bss section, thus breaking it's usage before the .bss is
> > > cleared.
> > >
> > > Move and rename the call to xen_reserve_extra_memory() so it's done in the
> > > x86_init.oem.arch_setup hook, which gets executed after the .bss has been
> > > zeroed, but before calling e820__memory_setup().
> > >
> > > Fixes: 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH')
> > > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > > ---
> > > While the commit that introduced the user-noticeable regression is
> > > 73db3abdca58c, I think 38620fc4e893 should have been more careful to not
> > > initialize the memblock ranges ahead of the .bss zeroing.
> > Reviewed-by: Juergen Gross <jgross@xxxxxxxx>
> >
> > I'd prefer using 73db3abdca58c for the fixes tag. Otherwise you'd need to
> > add this patch to the stable branches, too, which is technically not really
> > needed.
> >
> > Additionally I'd like to drop the Fixes: tag from the prereq patch, as this
> > one doesn't really fix anything.
> >
> > I can do both while committing.
> I was unsure myself (as noted in the post-commit notes) about which
> "Fixes:" tag to use.
>
> Is there anyway that it can be noted that this commit depends on the
> previous change also being present?  For backport reasons, if anyone
> ends up backporting 73db3abdca58c it would also need to pick the two
> patches here.
This is normal business of backporting. This patch added to a stable kernel
would at least result in a build failure. The person doing the backport could
it either fixup locally in the backported patch, or look which patch did setup
the source to make this patch work.


Juergen