Message ID | 20230525025555.24104-3-songshuaishuai@tinylab.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp73324vqr; Wed, 24 May 2023 19:58:31 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7mNgEee3PxmDTQHG6xaGrZ1lnMcC3Cy7VqvefhTJxbAPjvZxDOaKj99Uhc8m42r8ER/ZGy X-Received: by 2002:a17:903:230f:b0:1af:a03:8d82 with SMTP id d15-20020a170903230f00b001af0a038d82mr43470plh.57.1684983510820; Wed, 24 May 2023 19:58:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684983510; cv=none; d=google.com; s=arc-20160816; b=whXMu7vkER55d90rIYIyXBLrDl/2brQYRMrUn+z6Go3YKQZV8Ern55VSf1RD+2E7W5 RA0YJhOq1t+WlhTqBLhr2BscqOIM9dbnm208pRd8seqz5/slNz2QRkKetZ2EDS3u0De/ ZmBxPjhbi3v+yanIQihzMSboLJqBbi8dsg8c7I6k8QaKVB3Wz35O/1XMkyjCepm8mmKb szQwqbRmMwIotaQ30Mbovuh1tR4swHR172oMoBwpSdKCrVUJ7Hnms10yym5dTLnhfZkR MbdJ6TMk7UWT5iTj5mg3qXK21IGg7l+Xl/b8B7Wo+nsYP8m4BnxfRwsLJKHK8vkJ/ZLN SeyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:feedback-id:content-transfer-encoding :mime-version:references:in-reply-to:message-id:date:subject:cc:to :from; bh=c6PZZmRlbY7pi4pQluO9dk4A2LvkMJhZOfQ0wEhbjc0=; b=ZnhSS0SEtBih4fbBqn5SQ8pJothtGCr9bcY9o5LeokJx0bRhxGwnZ16qD5KmVfW7B8 P5b59rny9OdigJu8pNZ0ABux/BY4XCGM8Z+Tqj32IMYqFPjEAlCGNDSwnmXaUYrXMpns QC16vtFcSlErjEq5rN8bds2JFMruWKSdPNpWRcJI2T/fubGyFRSxaFy4MEU5XJHgoRgM prVyAvuge5XLEYfUNPKliRgOX+Nv7JrM63PcYwjqjW/rXm6Z/ywttvtys3VO6ErqFQ52 V0nKxI52dCb01sbYD5/yZwdHq3EtAfLW38y/b6PrneNr0c7iv+cNxDVmn57zWfEPX5vB LGlQ== 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a5-20020a170902ecc500b001ac84f87b0fsi160662plh.339.2023.05.24.19.58.16; Wed, 24 May 2023 19:58:30 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234199AbjEYC5u (ORCPT <rfc822;ahmedalshaiji.dev@gmail.com> + 99 others); Wed, 24 May 2023 22:57:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229489AbjEYC5r (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 24 May 2023 22:57:47 -0400 Received: from bg4.exmail.qq.com (bg4.exmail.qq.com [43.154.221.58]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43354135 for <linux-kernel@vger.kernel.org>; Wed, 24 May 2023 19:57:43 -0700 (PDT) X-QQ-mid: bizesmtp63t1684983430tny3hp8d Received: from localhost.localdomain ( [221.226.144.218]) by bizesmtp.qq.com (ESMTP) with id ; Thu, 25 May 2023 10:57:08 +0800 (CST) X-QQ-SSF: 01200000000000303000000A0000000 X-QQ-FEAT: Q40xx9djesRnvDjNn8FEKK30CJtqMZLJIor2xKhK5CaxBB9mt0DXuMlLPYqPB XwU+t+ZR2ppVV1gWFz/3tdYgXvOqNyx2sj1tDRvmvPJSxWf9mmIV9/kKzgpyLRFF6pAKMpv dB0eKB2SSKXJh3FTbdTch41OWKYEWPRex1/kKW7pZjOibMJK72PzfbAwoYu0dNrdZKe15AK dTMzuKSl3z/YxPs5jNKNOm7HuebEE7nCnLbDXy5qf6ij3OKz81p/au9NFgD8Zl6iWkiPEDq GcW6VwoPGDF1TVFO2o+HzRuvCW71F1mCYe/bYfS8TJHE/z7e4lhSzEBaQvPwUFBEwu87AX9 fT3d27frdI1M3q8tgGm3Jw0nwmLKBJdf6njsyPLQRlj+Yw3Q4gHY9U0yQCyzavwq1c5rNIA X-QQ-GoodBg: 0 X-BIZMAIL-ID: 4042248179779979880 From: Song Shuai <songshuaishuai@tinylab.org> To: catalin.marinas@arm.com, will@kernel.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, chris@zankel.net, jcmvbkbc@gmail.com, songshuaishuai@tinylab.org, steven.price@arm.com, vincenzo.frascino@arm.com, pcc@google.com, wangxiang@cdjrlc.com, ajones@ventanamicro.com, conor.dooley@microchip.com, jeeheng.sia@starfivetech.com, leyfoon.tan@starfivetech.com Cc: linux@armlinux.org.uk, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: [PATCH 2/4] arm64: hibernate: remove WARN_ON in save_processor_state Date: Thu, 25 May 2023 10:55:53 +0800 Message-Id: <20230525025555.24104-3-songshuaishuai@tinylab.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20230525025555.24104-1-songshuaishuai@tinylab.org> References: <20230525025555.24104-1-songshuaishuai@tinylab.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:tinylab.org:qybglogicsvrgz:qybglogicsvrgz5a-3 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766833269630679166?= X-GMAIL-MSGID: =?utf-8?q?1766833269630679166?= |
Series |
Remove WARN_ON in save_processor_state
|
|
Commit Message
Song Shuai
May 25, 2023, 2:55 a.m. UTC
During hibernation or restoration, freeze_secondary_cpus
checks num_online_cpus via BUG_ON, and the subsequent
save_processor_state also does the checking with WARN_ON.
So remove the unnecessary checking in save_processor_state.
Signed-off-by: Song Shuai <songshuaishuai@tinylab.org>
---
arch/arm64/kernel/hibernate.c | 1 -
1 file changed, 1 deletion(-)
Comments
On Thu, May 25, 2023 at 10:55:53AM +0800, Song Shuai wrote: > During hibernation or restoration, freeze_secondary_cpus > checks num_online_cpus via BUG_ON, and the subsequent > save_processor_state also does the checking with WARN_ON. > > So remove the unnecessary checking in save_processor_state. This is a very terse summary of why this is safe. Looking at the code, freeze_secondary_cpus() does indeed check num_online_cpus(), or it returns an error which then causes the hibernation to fail. However, this is all in the CONFIG_PM_SLEEP_SMP=y case and it's far less clear whether your assertion is true if that option is disabled. Please can you describe your reasoning in more detail, and cover the case where CONFIG_PM_SLEEP_SMP=n as well, please? Will
在 2023/6/5 22:28, Will Deacon 写道: > On Thu, May 25, 2023 at 10:55:53AM +0800, Song Shuai wrote: >> During hibernation or restoration, freeze_secondary_cpus >> checks num_online_cpus via BUG_ON, and the subsequent >> save_processor_state also does the checking with WARN_ON. >> >> So remove the unnecessary checking in save_processor_state. > > This is a very terse summary of why this is safe. > > Looking at the code, freeze_secondary_cpus() does indeed check > num_online_cpus(), or it returns an error which then causes the hibernation > to fail. However, this is all in the CONFIG_PM_SLEEP_SMP=y case and it's > far less clear whether your assertion is true if that option is disabled. > > Please can you describe your reasoning in more detail, and cover the case > where CONFIG_PM_SLEEP_SMP=n as well, please? With HIBERNATION enabled, the sole possible condition to disable CONFIG_PM_SLEEP_SMP is !SMP where num_online_cpus is always 1. We also don't have to check it in save_processor_state. > > Will >
On Wed, Jun 07, 2023 at 11:00:08AM +0800, Song Shuai wrote: > > > 在 2023/6/5 22:28, Will Deacon 写道: > > On Thu, May 25, 2023 at 10:55:53AM +0800, Song Shuai wrote: > > > During hibernation or restoration, freeze_secondary_cpus > > > checks num_online_cpus via BUG_ON, and the subsequent > > > save_processor_state also does the checking with WARN_ON. > > > > > > So remove the unnecessary checking in save_processor_state. > > > > This is a very terse summary of why this is safe. > > > > Looking at the code, freeze_secondary_cpus() does indeed check > > num_online_cpus(), or it returns an error which then causes the hibernation > > to fail. However, this is all in the CONFIG_PM_SLEEP_SMP=y case and it's > > far less clear whether your assertion is true if that option is disabled. > > > > Please can you describe your reasoning in more detail, and cover the case > > where CONFIG_PM_SLEEP_SMP=n as well, please? > > With HIBERNATION enabled, the sole possible condition to disable > CONFIG_PM_SLEEP_SMP > is !SMP where num_online_cpus is always 1. We also don't have to check it in > save_processor_state. Thanks. Please add that to the commit message. Will
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c index 788597a6b6a2..02870beb271e 100644 --- a/arch/arm64/kernel/hibernate.c +++ b/arch/arm64/kernel/hibernate.c @@ -99,7 +99,6 @@ int pfn_is_nosave(unsigned long pfn) void notrace save_processor_state(void) { - WARN_ON(num_online_cpus() != 1); } void notrace restore_processor_state(void)