Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp240037pxb; Tue, 15 Feb 2022 12:13:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJxdnlLrhdI6WikmS4+ouFKVdS4Cmgy6q8Pa25DIHzaEAT2EVzQyOymo9wv8F81vHVLoW2yd X-Received: by 2002:a17:90b:2251:b0:1b8:c4cc:2057 with SMTP id hk17-20020a17090b225100b001b8c4cc2057mr6111210pjb.193.1644956017962; Tue, 15 Feb 2022 12:13:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644956017; cv=none; d=google.com; s=arc-20160816; b=IK5D+aUYkanqQnVuvHTNBrZCSf71akHNhDC2Ye0IqUsY/UsQNPDTwxAVAx02Wn63/7 DmRyfd+OW5FHvlqnWZAdNZvuOOPrLcA8HxM3OgYdz2Od8l/8wLr0rfkbVmlqthXWaQXK I9YGS6w+150S2xjPnVFkwhXDidhr5GfabfFx4GmZV4eCCxpc+EZ8Ocdw3D/07CUSVaNQ VqAYFAeKmPM9avlksAUNYXGfkHZENaO3oN48s8Fa+VtR9vHj3+GZjnNOCinl/mQPYWNr h75GiH9mDts5trqtbD+BKwcPv4q6G06ymbc8YVuwQsj6wztBjq4JbNzfBFg2DlTNemcE KINA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=SLFv4waeo5YuoRAUVGegv4SpTYX4MddFjHCih3shNqw=; b=kukfJjqijJVeB6gnO9AneoARCiqwR9phfedvogINbNYb8rD9v9HRRBsVFYzoqT6YqI hTvFGjXDHOVyUbzdJjgEsOK/xnxuzeA9+c4pJX2Aw2uRr95Q2FOUub4XaofARGf/TSi9 HioTHHAcYbe4AvFTvs+UAT9bYy/qE+81FKLUKV9bbJs5LAD9dclbiEZnouYMUPWTObkI B4WQ0J9KX5aKGSKbE4pxKCH0Oh4tGKf6T698Z31/F07g8m70olash+CBWbVobTz+fmrp hJeD8hAgZ4LqpKDIAZQLACTcy+TjJ59lTlyufhVPZAbIK30safi/Rq2MBc1PpTzd9Gvq iNFQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q4si18033458plk.96.2022.02.15.12.13.21; Tue, 15 Feb 2022 12:13:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236219AbiBOOLG convert rfc822-to-8bit (ORCPT + 99 others); Tue, 15 Feb 2022 09:11:06 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:46440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229896AbiBOOLF (ORCPT ); Tue, 15 Feb 2022 09:11:05 -0500 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FE047D2AB; Tue, 15 Feb 2022 06:10:55 -0800 (PST) Received: by mail-yb1-f181.google.com with SMTP id v186so56458626ybg.1; Tue, 15 Feb 2022 06:10:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xHfL1XY2GV6QdZjIkT4vEos4l6sqpCi5W/kB5ImUf2I=; b=wnzmPXUvPcJ3683Ztz3p4zLPfMTTG/bb8eWY++hxELKDoT6zzqN0s2jirNyjljnSH1 XKcpCqCdVbf4FVZ7JO7uzipctkQniwFpkd1vWA0kBt2CrddXBnp+CeEIy1hnEfWYBCVY Zxp8DfoRdSxJRf+FsKjSsXEcIccEgLqFNW1jGxOg4sX/RW8V2yRhjckkjDJDSWUDzbBD wMjxtDS6ftC9yn/DiX/XM80hP16OwZsR7MfDklm1fepwNt8VNuxM6OOIY/1vvvDXkq+U 58A7ytNAB7DIBjyiU4DdpIHOBaj18TmBjoMMoMa5cCqmITtDVg/K5yxUnqcOviBjR6JC lY5w== X-Gm-Message-State: AOAM533j8oAm+Xvy6xGBCW+G8WP6hK53dsK+QxPOCoqD0d51Ii0XA/yf zD9EEF5osp0ozaGKyaysEwyoUBk6nQlB88BO7lo= X-Received: by 2002:a81:1f0b:: with SMTP id f11mr3887472ywf.149.1644934254475; Tue, 15 Feb 2022 06:10:54 -0800 (PST) MIME-Version: 1.0 References: <20220121103938.2602637-1-amadeuszx.slawinski@linux.intel.com> <59ef4cd5-5703-2356-c893-9858985f91e0@intel.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 15 Feb 2022 15:10:43 +0100 Message-ID: Subject: Re: [PATCH] x86: Preserve ACPI memory area during hibernation To: =?UTF-8?B?QW1hZGV1c3ogU8WCYXdpxYRza2k=?= Cc: "Rafael J. Wysocki" , "the arch/x86 maintainers" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Linux Kernel Mailing List , Cezary Rojewski , Linux PM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 15, 2022 at 1:22 PM Amadeusz Sławiński 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!