[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230605142857.GE21212@willie-the-truck>
Date: Mon, 5 Jun 2023 15:28:58 +0100
From: Will Deacon <will@...nel.org>
To: Song Shuai <songshuaishuai@...ylab.org>
Cc: catalin.marinas@....com, paul.walmsley@...ive.com,
palmer@...belt.com, aou@...s.berkeley.edu, chris@...kel.net,
jcmvbkbc@...il.com, steven.price@....com,
vincenzo.frascino@....com, pcc@...gle.com, wangxiang@...rlc.com,
ajones@...tanamicro.com, conor.dooley@...rochip.com,
jeeheng.sia@...rfivetech.com, leyfoon.tan@...rfivetech.com,
linux@...linux.org.uk, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH 2/4] arm64: hibernate: remove WARN_ON in
save_processor_state
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
Powered by blists - more mailing lists