[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f6e5f716-f191-c126-cc81-cf872ad4e750@linux.intel.com>
Date: Tue, 15 Feb 2022 13:22:12 +0100
From: Amadeusz Sławiński
<amadeuszx.slawinski@...ux.intel.com>
To: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H . Peter Anvin" <hpa@...or.com>
Cc: linux-kernel@...r.kernel.org,
Cezary Rojewski <cezary.rojewski@...el.com>,
Linux PM <linux-pm@...r.kernel.org>
Subject: Re: [PATCH] x86: Preserve ACPI memory area during hibernation
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.
Powered by blists - more mailing lists