linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vitaly Wool <vitaly.wool@konsulko.com>
To: Liu Shixin <liushixin2@huawei.com>
Cc: Seth Jennings <sjenning@redhat.com>,
	Dan Streetman <ddstreet@ieee.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Nathan Chancellor <nathan@kernel.org>,
	 Christoph Hellwig <hch@lst.de>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	 Kefeng Wang <wangkefeng.wang@huawei.com>
Subject: Re: [PATCH -next v3 1/5] frontswap: skip frontswap_ops init if zswap init failed.
Date: Mon, 29 Aug 2022 08:11:37 +0200	[thread overview]
Message-ID: <CAM4kBB+UK4pSB1VtJNQuDre2QrExCAyOHa5Y7MMU=q++RpyhSQ@mail.gmail.com> (raw)
In-Reply-To: <06a79a47-727f-fae2-4620-dcf6703efacb@huawei.com>

On Mon, Aug 29, 2022 at 4:11 AM Liu Shixin <liushixin2@huawei.com> wrote:
>
> On 2022/8/29 4:44, Vitaly Wool wrote:
> > On Sat, Aug 27, 2022 at 12:12 PM Liu Shixin <liushixin2@huawei.com> wrote:
> >> If zswap initial failed or has not been initial, frontswap_ops will be
> >> NULL. In such situation, swap device would enable failed with following
> >> stack trace:
> >>
> >>   Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000
> >>   Mem abort info:
> >>     ESR = 0x0000000096000004
> >>     EC = 0x25: DABT (current EL), IL = 32 bits
> >>     SET = 0, FnV = 0
> >>     EA = 0, S1PTW = 0
> >>     FSC = 0x04: level 0 translation fault
> >>   Data abort info:
> >>     ISV = 0, ISS = 0x00000004
> >>     CM = 0, WnR = 0
> >>   user pgtable: 4k pages, 48-bit VAs, pgdp=00000020a4fab000
> >>   [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
> >>   Internal error: Oops: 96000004 [#1] SMP
> >>   Modules linked in: zram fsl_dpaa2_eth pcs_lynx phylink ahci_qoriq crct10dif_ce ghash_ce sbsa_gwdt fsl_mc_dpio nvme lm90 nvme_core at803x xhci_plat_hcd rtc_fsl_ftm_alarm xgmac_mdio ahci_platform i2c_imx ip6_tables ip_tables fuse
> >>   Unloaded tainted modules: cppc_cpufreq():1
> >>   CPU: 10 PID: 761 Comm: swapon Not tainted 6.0.0-rc2-00454-g22100432cf14 #1
> >>   Hardware name: SolidRun Ltd. SolidRun CEX7 Platform, BIOS EDK II Jun 21 2022
> >>   pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> >>   pc : frontswap_init+0x38/0x60
> >>   lr : __do_sys_swapon+0x8a8/0x9f4
> >>   sp : ffff80000969bcf0
> >>   x29: ffff80000969bcf0 x28: ffff37bee0d8fc00 x27: ffff80000a7f5000
> >>   x26: fffffcdefb971e80 x25: ffffaba797453b90 x24: 0000000000000064
> >>   x23: ffff37c1f209d1a8 x22: ffff37bee880e000 x21: ffffaba797748560
> >>   x20: ffff37bee0d8fce4 x19: ffffaba797748488 x18: 0000000000000014
> >>   x17: 0000000030ec029a x16: ffffaba795a479b0 x15: 0000000000000000
> >>   x14: 0000000000000000 x13: 0000000000000030 x12: 0000000000000001
> >>   x11: ffff37c63c0aba18 x10: 0000000000000000 x9 : ffffaba7956b8c88
> >>   x8 : ffff80000969bcd0 x7 : 0000000000000000 x6 : 0000000000000000
> >>   x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffffaba79730f000
> >>   x2 : ffff37bee0d8fc00 x1 : 0000000000000000 x0 : 0000000000000000
> >>   Call trace:
> >>   frontswap_init+0x38/0x60
> >>   __do_sys_swapon+0x8a8/0x9f4
> >>   __arm64_sys_swapon+0x28/0x3c
> >>   invoke_syscall+0x78/0x100
> >>   el0_svc_common.constprop.0+0xd4/0xf4
> >>   do_el0_svc+0x38/0x4c
> >>   el0_svc+0x34/0x10c
> >>   el0t_64_sync_handler+0x11c/0x150
> >>   el0t_64_sync+0x190/0x194
> >>   Code: d000e283 910003fd f9006c41 f946d461 (f9400021)
> >>   ---[ end trace 0000000000000000 ]---
> >>
> > Well, this issue you are seeing is in fact introduced by the following patch:
> >
> > author Christoph Hellwig <hch@lst.de> 2022-01-21 22:15:10 -0800
> > frontswap: remove support for multiple ops
> >
> > So I would rather see that one reverted and fixed.
> >
> > Thanks,
> > Vitaly
> It is surely introduced by the previous patch ,but is it need to revert that patch? Do we have
> any plans to add new backend in the future?

I believe we do. Besides, this patch introduces the bug you have hit,
before this patch frontswap just wouldn't go doing anything on an
empty list.
It's my bad I didn't NAK that patch then, but we have an opportunity
to do it the right way now.

Thanks,
Vitaly

> Thanks,
> >
> >> Reported-by: Nathan Chancellor <nathan@kernel.org>
> >> Signed-off-by: Liu Shixin <liushixin2@huawei.com>
> >> ---
> >>  mm/frontswap.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/mm/frontswap.c b/mm/frontswap.c
> >> index 1a97610308cb..620f95af81dd 100644
> >> --- a/mm/frontswap.c
> >> +++ b/mm/frontswap.c
> >> @@ -125,7 +125,8 @@ void frontswap_init(unsigned type, unsigned long *map)
> >>          * p->frontswap set to something valid to work properly.
> >>          */
> >>         frontswap_map_set(sis, map);
> >> -       frontswap_ops->init(type);
> >> +       if (frontswap_ops)
> >> +               frontswap_ops->init(type);
> >>  }
> >>
> >>  static bool __frontswap_test(struct swap_info_struct *sis,
> >> --
> >> 2.25.1
> >>
> > .
> >
>


  reply	other threads:[~2022-08-29  6:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-27 10:45 [PATCH -next v3 0/5] Delay the initializaton of zswap Liu Shixin
2022-08-27 10:45 ` [PATCH -next v3 1/5] frontswap: skip frontswap_ops init if zswap init failed Liu Shixin
2022-08-28 20:44   ` Vitaly Wool
2022-08-29  2:10     ` Liu Shixin
2022-08-29  6:11       ` Vitaly Wool [this message]
2022-08-27 10:45 ` [PATCH -next v3 2/5] frontswap: invoke ops->init for online swap device in frontswap_register_ops Liu Shixin
2022-08-28 20:47   ` Vitaly Wool
2022-08-29  2:12     ` Liu Shixin
2022-08-27 10:45 ` [PATCH -next v3 3/5] mm/zswap: replace zswap_init_{started/failed} with zswap_init_state Liu Shixin
2022-08-28 20:46   ` Vitaly Wool
2022-08-27 10:45 ` [PATCH -next v3 4/5] mm/zswap: delay the initializaton of zswap until the first enablement Liu Shixin
2022-08-28 20:45   ` Vitaly Wool
2022-08-27 10:46 ` [PATCH -next v3 5/5] mm/zswap: skip confusing print info Liu Shixin
2022-08-27 22:13 ` [PATCH -next v3 0/5] Delay the initializaton of zswap Andrew Morton

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='CAM4kBB+UK4pSB1VtJNQuDre2QrExCAyOHa5Y7MMU=q++RpyhSQ@mail.gmail.com' \
    --to=vitaly.wool@konsulko.com \
    --cc=akpm@linux-foundation.org \
    --cc=ddstreet@ieee.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liushixin2@huawei.com \
    --cc=nathan@kernel.org \
    --cc=sjenning@redhat.com \
    --cc=wangkefeng.wang@huawei.com \
    /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