From: Mike Rapoport <rppt@kernel.org>
To: David Hildenbrand <david@redhat.com>, Yaxiong Tian <13327272236@163.com>
Cc: rafael@kernel.org, pavel@ucw.cz, len.brown@intel.com,
keescook@chromium.org, tony.luck@intel.com, gpiccoli@igalia.com,
akpm@linux-foundation.org, ardb@kernel.org,
wangkefeng.wang@huawei.com, catalin.marinas@arm.com,
will@kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
Yaxiong Tian <tianyaxiong@kylinos.cn>,
xiongxin <xiongxin@kylinos.cn>
Subject: Re: [PATCH] PM: hibernate: Fix level3 translation fault in swsusp_save()
Date: Mon, 26 Feb 2024 11:14:24 +0200 [thread overview]
Message-ID: <ZdxWcG2XCqBum3_R@kernel.org> (raw)
In-Reply-To: <8d70939f-ca14-4167-9647-b8f44ddcbb98@redhat.com>
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@kylinos.cn>
> >
> > 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?
> > [ 48.532162] Unable to handle kernel paging request at virtual address ffffff8000000000
> > [ 48.532162] Mem abort info:
> > [ 48.532162] ESR = 0x0000000096000007
> > [ 48.532162] EC = 0x25: DABT (current EL), IL = 32 bits
> > [ 48.532162] SET = 0, FnV = 0
> > [ 48.532162] EA = 0, S1PTW = 0
> > [ 48.532162] FSC = 0x07: level 3 translation fault
> > [ 48.532162] Data abort info:
> > [ 48.532162] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
> > [ 48.532162] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> > [ 48.532162] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> > [ 48.532162] swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000
> > [ 48.532162] [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000
> > [ 48.532162] Internal error: Oops: 0000000096000007 [#1] SMP
> > [ 48.532162] Internal error: Oops: 0000000096000007 [#1] SMP
> > [ 48.532162] Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm
> > [ 48.532162] CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76
> > [ 48.532162] Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0
> > [ 48.532162] Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021
> > [ 48.532162] pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [ 48.532162] pc : swsusp_save+0x280/0x538
> > [ 48.532162] lr : swsusp_save+0x280/0x538
> > [ 48.532162] sp : ffffffa034a3fa40
> > [ 48.532162] x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000
> > [ 48.532162] x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000
> > [ 48.532162] x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2
> > [ 48.532162] x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000
> > [ 48.532162] x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666
> > [ 48.532162] x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea
> > [ 48.532162] x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0
> > [ 48.532162] x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001
> > [ 48.532162] x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027
> > [ 48.532162] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e
> > [ 48.532162] Call trace:
> > [ 48.532162] swsusp_save+0x280/0x538
> > [ 48.532162] swsusp_arch_suspend+0x148/0x190
> > [ 48.532162] hibernation_snapshot+0x240/0x39c
> > [ 48.532162] hibernate+0xc4/0x378
> > [ 48.532162] state_store+0xf0/0x10c
> > [ 48.532162] kobj_attr_store+0x14/0x24
> >
> > QEMU ARM64 using UEFI also has the problem by setting can_set_direct_map()
> > return false.
Huh?
Why would you do that?
> >
> > Since the NOMAP regions are now marked as PageReserved(), pfn walkers
> > and the rest of core mm will treat them as unusable memory. So this
> > regions should not saved in hibernation.
> >
> > This problem may cause by changes to pfn_valid() logic in commit
> > a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplify pfn_valid()").
> >
> > So to fix it, we add pfn_is_map_memory() check in saveable_page(). It
> > make such regisons don't save in hibernation.
> >
> > Fixes: a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplify pfn_valid()")
> > Co-developed-by: xiongxin <xiongxin@kylinos.cn>
> > Signed-off-by: xiongxin <xiongxin@kylinos.cn>
> > Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
> > ---
> > kernel/power/snapshot.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> > index 0f12e0a97e43..a06e3b1869d2 100644
> > --- a/kernel/power/snapshot.c
> > +++ b/kernel/power/snapshot.c
> > @@ -1400,7 +1400,7 @@ static struct page *saveable_page(struct zone *zone, unsigned long pfn)
> > return NULL;
> > if (PageReserved(page)
> > - && (!kernel_page_present(page) || pfn_is_nosave(pfn)))
> > + && (!kernel_page_present(page) || pfn_is_nosave(pfn) || !pfn_is_map_memory(pfn)))
I think adding the check for !pfn_is_map_memory() to arm64::pfn_is_nosave()
is the best way to fix this.
> > return NULL;
> > if (page_is_guard(page))
>
> On top of which tree does this apply?
>
> All occurrences of pfn_is_map_memory() are in arch/arm64, how does this
> compile on other architectures?
>
> --
> Cheers,
>
> David / dhildenb
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2024-02-26 9:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 3:42 [PATCH] PM: hibernate: Fix level3 translation fault in swsusp_save() Yaxiong Tian
2024-02-26 8:37 ` David Hildenbrand
2024-02-26 9:14 ` Mike Rapoport [this message]
2024-02-27 7:51 ` Yaxiong Tian
2024-02-29 9:42 ` Mike Rapoport
2024-03-01 2:19 ` [PATCH v2] arm64: " Yaxiong Tian
2024-04-12 17:30 ` Catalin Marinas
2024-04-17 2:13 ` Yaxiong Tian
2024-03-01 2:55 ` [PATCH] PM: " Yaxiong Tian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZdxWcG2XCqBum3_R@kernel.org \
--to=rppt@kernel.org \
--cc=13327272236@163.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=gpiccoli@igalia.com \
--cc=keescook@chromium.org \
--cc=len.brown@intel.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
--cc=tianyaxiong@kylinos.cn \
--cc=tony.luck@intel.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=xiongxin@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox