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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJZ5v0jV5H9a66utA5Ch--X2iiV-MOSmX6CVL6s+veYpzOaezg@mail.gmail.com>
Date:   Tue, 15 Feb 2022 15:10:43 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Amadeusz Sławiński 
        <amadeuszx.slawinski@...ux.intel.com>
Cc:     "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        "the arch/x86 maintainers" <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>,
        Linux Kernel Mailing List <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 Tue, Feb 15, 2022 at 1:22 PM Amadeusz Sławiński
<amadeuszx.slawinski@...ux.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!