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

["Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>]

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.