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

["Jürgen Groß" <jgross@suse.com>]

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@citrix.com>
>>> ---
>>> 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@suse.com>
>>
>> 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