Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp35207pxb; Tue, 15 Feb 2022 08:00:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJwblYR75caSn9iYEwjoy6Com/RuJW7/oSKKuMm7KHvCbRppQMF83nCp9OsYeyucesbeDwPn X-Received: by 2002:a05:6402:2714:: with SMTP id y20mr4691260edd.329.1644940852887; Tue, 15 Feb 2022 08:00:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644940852; cv=none; d=google.com; s=arc-20160816; b=Xo+MHM2949+FmIhYWpVbGVQCqleljXV2fdDp4Qwiz3VkOcuAfKYcaLaPPny2cncvlI jWB5x+s8WBMthXlzAZUcIlqTDpq2zj33/idz6BZIcIGVwNY7VEGxvkPEdHsai/XdP2Ic cNL/nCtpnB5hUzLKdIy4MAxM5sXdtFv6elj/LB5nzi2rrACws6oFZTHNpwAyNLc8p//y XhmtrfVJnlumWAltLyYTmv4I3RJVzgxtn6ZlaWvn59zqGT76XGqWQAGCQ4tVYHwxIEHB 1YBqI8/7oLmRxOzy5wP10O3gLaa2LXGG/RG9VjavXVMY/uZewijk0DbjPzdh+4+cxYU1 opjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=OSy/s62zg6CcqiQE683O9nMDBFi+gIouk/SXp4LGHgQ=; b=JVSFutbWSOLMb5IOsVNn1nvLLhhKQfWsrgsKY+nS3FAbEU3vNsq4zRSX5dSD3Oga2l DLe+2Na2FgbfN223nJWDiAW9TqKB9LSQ+VZtbb9bP3ygteHy9uDS6IcOTuOKuJb5v9MI qLheWhKd3cig1/re+ZwJS4Ni/d70SFKLTYy503o6K4BKWza7wNcFC8NzBJ5ccp2BlTgr rreDnjPLa+4zP7LHat0ubdTMYTCVeMrC+Hr+fC98pprlLkmwZ0WS92KGUgulTIdMvvpR KTrlwgcx/8Ge4yQwQkZvIQXMZRcM5R8kRvYNGlbZJqHnMgL4jr7ptWDuMVowkk18kaGz OZHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=K18fhYO+; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gk1si20192383ejc.868.2022.02.15.08.00.29; Tue, 15 Feb 2022 08:00:52 -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; dkim=pass header.i=@intel.com header.s=Intel header.b=K18fhYO+; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232882AbiBOMW3 (ORCPT + 99 others); Tue, 15 Feb 2022 07:22:29 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:60866 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229997AbiBOMW1 (ORCPT ); Tue, 15 Feb 2022 07:22:27 -0500 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE3D8652D8; Tue, 15 Feb 2022 04:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644927738; x=1676463738; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=9Z5qiYvDYgVNlV1KxkkI+JpsTNmfMXnWh+xwt4Boy3U=; b=K18fhYO+cO1+R1f4gdB/AxhnKjtkK43b06/+vItf5eOs7JpPkTXVcJ2e iHM1kJFYe+/quot+2cHbQ+ww463J0TnEMipp7YOM5Nz6nsHJIZ+s81AXJ HHLRg/v8RS/CMlteHDZ8pNaGUc8g2nIuni9NpXuc1tcEY31AMISFlg/cP vFklBoGU6+B4tjJEuNMgs+PsFuoZpi9LE5fr5wIgWePozIE1Ew/rhYv0H 3dGqsaGvHbmAbdijmnC568gjGQqrcaQAR6Auvi7L5SV4izrEkDKw9mm9L vJRTMoAreyMML98quevfyB1Q8DVngqidABpRzZXlRUf4xHTwz3/dJR5cM w==; X-IronPort-AV: E=McAfee;i="6200,9189,10258"; a="250081081" X-IronPort-AV: E=Sophos;i="5.88,370,1635231600"; d="scan'208";a="250081081" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Feb 2022 04:22:17 -0800 X-IronPort-AV: E=Sophos;i="5.88,370,1635231600"; d="scan'208";a="544277902" Received: from aslawinx-mobl.ger.corp.intel.com (HELO [10.99.249.196]) ([10.99.249.196]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Feb 2022 04:22:14 -0800 Message-ID: Date: Tue, 15 Feb 2022 13:22:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH] x86: Preserve ACPI memory area during hibernation Content-Language: en-US To: "Rafael J. Wysocki" , x86@kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" Cc: linux-kernel@vger.kernel.org, Cezary Rojewski , Linux PM References: <20220121103938.2602637-1-amadeuszx.slawinski@linux.intel.com> <59ef4cd5-5703-2356-c893-9858985f91e0@intel.com> From: =?UTF-8?Q?Amadeusz_S=c5=82awi=c5=84ski?= In-Reply-To: <59ef4cd5-5703-2356-c893-9858985f91e0@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham 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 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.