Re: [PATCH] PM: hibernate: Fix level3 translation fault in swsusp_save()

[Yaxiong Tian]

在 2024/2/29 17:42, Mike Rapoport 写道:
> On Tue, Feb 27, 2024 at 03:51:25PM +0800, Yaxiong Tian wrote:
> > 在 2024/2/26 17:14, Mike Rapoport 写道:
> > > On Mon, Feb 26, 2024 at 09:37:06AM +0100, David Hildenbrand wrote:
> > > > On 26.02.24 04:42, Yaxiong Tian wrote:
> > > > > From: Yaxiong Tian <tianyaxiong@xxxxxxxxxx>
> > > > >
> > > > > On ARM64 machines using UEFI, if the linear map is not set (can_set_direct_map()
> > > > > return false), swsusp_save() will fail due to can't finding the map table
> > > > > under the nomap memory.such as:
> > > can_set_direct_map() has nothing to do with presence or absence of the
> > > linear map.
> > >
> > > Do you mean that kernel_page_present() presumes that a page is present when
> > > can_set_direct_map() returns false even for NOMAP ranges?
> > Yes， in swsusp_save()->copy_data_pages()->page_is_saveable(),
> > kernel_page_present() presumes that a page is present when
> > can_set_direct_map()
> > returns false even for NOMAP ranges.So NOMAP pages will saved in after,and
> > then
> > cause level3 translation fault in this pages.
> So this should be the description of the problem in the changelog rather
> than saying "if the linear map is not set (can_set_direct_map() return
> false)"
>
> > > > > QEMU ARM64 using UEFI also has the problem by setting can_set_direct_map()
> > > > > return false.
> > > Huh?
> > > Why would you do that?
> > I discovered this problem when upgrading from 5.4 to 6.6 using the 5.4
> > configuration.
> > So I using latest linux-next code,find the problem still exist.To rule out
> > the effects
> > of a particular machine，I also use qemu to check it.
> I believe this can be reproduced if you boot with rodata=off and then
> a better description would be something like
>
> 	This issue can be reproduced in QEMU when booting with rodata=off

Thanks, I opt commit messages,and move !pfn_is_map_memory() check from 
page_is_saveable()
to arm64::pfn_is_nosave().  The patch v2 is in:

https://lore.kernel.org/all/20240301021924.33210-1-13327272236@xxxxxxx/

I heard that if it is a single PATCH it should be placed under the 
original mailing list,
so please ignore the February 27 patch mailing.

>