Re: [PATCH] x86: Preserve ACPI memory area during hibernation

["Rafael J. Wysocki" <rafael@kernel.org>]

On Tue, Feb 15, 2022 at 1:22 PM Amadeusz Sławiński
<amadeuszx.slawinski@linux.intel.com> wrote:
>
> On 2/14/2022 8:34 PM, Rafael J. Wysocki wrote:
> > On 1/21/2022 11:39 AM, Amadeusz Sławiński wrote:
> >> When overriding NHLT ACPI-table tests show that on some platforms
> >> there is problem that NHLT contains garbage after hibernation/resume
> >> cycle.
> >>
> >> Problem stems from the fact that ACPI override performs early memory
> >> allocation using memblock_phys_alloc_range() in
> >> memblock_phys_alloc_range(). This memory block is later being marked as
> >> ACPI memory block in arch_reserve_mem_area(). Later when memory areas
> >> are considered for hibernation it is being marked as nosave in
> >> e820__register_nosave_regions().
> >>
> >> Fix this by skipping ACPI memory area altogether when considering areas
> >> to mark as nosave.
> >
> > This patch looks correct to me and I'm going to apply it as 5.18
> > material unless there are any objections or concerns (in which case
> > please let me know).
> >
> >
>
> Well, what do you know? I've checked with validation team to make sure
> that it works as expected and while it causes no problem on almost all
> platforms and fixes problem with NHLT ACPI-table override, there is this
> one platform where it causes oops on hibernation which of course is gone
> after reverting the patch.
>
>   ? set_direct_map_default_noflush+0x130/0x130
>   ? memory_bm_test_bit+0x29/0x60
>   saveable_page+0xce/0xf2
>   count_data_pages+0x50/0x76
>   hibernate_preallocate_memory+0x9c/0x377
>   ? __mutex_lock_slowpath+0x20/0x20
>   hibernation_snapshot+0x1cf/0x610
>   snapshot_ioctl+0x3d2/0x690
>   ? snapshot_release+0xd0/0xd0
>   ? new_sync_write+0x36b/0x390
>   __x64_sys_ioctl+0x6dc/0xe20
>   ? vfs_fileattr_set+0x520/0x520
>   ? _raw_read_unlock+0x2a/0x50
>   ? __kasan_check_read+0x11/0x20
>   ? vfs_write+0x131/0x3d0
>   ? ksys_write+0x13b/0x170
>   ? debug_smp_processor_id+0x17/0x20
>   ? fpregs_assert_state_consistent+0x5f/0x70
>   ? exit_to_user_mode_prepare+0x3e/0x170
>   do_syscall_64+0x43/0x90
>   entry_SYSCALL_64_after_hwframe+0x44/0xae
>
> Above trace points at functions using pfn, so I suspect there may be
> need for some additional checks, but I will need to investigate.
> I guess you can skip this patch for now, until I figure what exactly is
> going on.

I'll do that, thanks!