From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8DB5C6FD1F for ; Thu, 21 Mar 2024 18:32:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 336186B0089; Thu, 21 Mar 2024 14:32:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E63D6B008C; Thu, 21 Mar 2024 14:32:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AE856B0092; Thu, 21 Mar 2024 14:32:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0AC336B0089 for ; Thu, 21 Mar 2024 14:32:14 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9C1CDA163D for ; Thu, 21 Mar 2024 18:32:13 +0000 (UTC) X-FDA: 81921890946.02.4B11C62 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) by imf10.hostedemail.com (Postfix) with ESMTP id BC8DEC001F for ; Thu, 21 Mar 2024 18:32:11 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=NDxMuWjy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of 3Kn38ZQoKCE0D376Dpw1tsv33v0t.r310x29C-11zAprz.36v@flex--yosryahmed.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=3Kn38ZQoKCE0D376Dpw1tsv33v0t.r310x29C-11zAprz.36v@flex--yosryahmed.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711045931; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/tDVqrg38EffykSVufOJs1REUSnSjvleZCiMCsYnZFs=; b=dXJn/gFiwgcmhnIF19gsBHPenUUWm6Pr0Qo80006jr2SCL6Zz6zYaznc63GpV7gKPX65Ui PYjkO9c4jilInc4SLeEs5pzXvg9aZjqUnw6linP8MkPGqRVo6jnhHBKyfYxBd+gc73hW+W XDLtofBKeh3jv3x8XqHRGvuZlsMxtTo= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=NDxMuWjy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of 3Kn38ZQoKCE0D376Dpw1tsv33v0t.r310x29C-11zAprz.36v@flex--yosryahmed.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=3Kn38ZQoKCE0D376Dpw1tsv33v0t.r310x29C-11zAprz.36v@flex--yosryahmed.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711045931; a=rsa-sha256; cv=none; b=5JYm933Z6JfJDVmvGyeAtoM+DE+lJkpl9eGvFUarYM2aZhiGusk7pmYytUGPS6qrFqi4hw fIhXo/oMFsi1nh0VWJAgKJAeVhphhhzHNS7pM+YW8JHOexiCn1YxnMBDeVfOBiebU0ybzi 6x9VyjBem/xxpmSDmXfGwSQnPATP+1U= Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-60a0b18e52dso16216827b3.1 for ; Thu, 21 Mar 2024 11:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1711045931; x=1711650731; darn=kvack.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=/tDVqrg38EffykSVufOJs1REUSnSjvleZCiMCsYnZFs=; b=NDxMuWjyB/gGdBdUQ6BCypcnGCCsCaeWCZcKIUmO23Lb7wp1Y80cwKa82mc2ZTy0mB XCs6aC8tVBkyIl2hGPmrafezxqlD53jpcHC37mkXUzXiMeHIFoOMlq+TEPfwfahGUJVg S0SVzOfmFLHyQmKW+ukpNxVX63R9qf4sFIIGTlcL7lyIFRsrq5OkbTEKTFeM1+e83eIZ R2wiCr2TvIdO9/DVn2vrBhxnndmTVuP8yKoUcfuCqiitwX0tOGbLfjDsBCvZvahbtnG7 gkoUwzMDo33uV5Dm7dWavuaGgLtqZpvozcoWHtUw08ct5M6Js9ayolFK8eGvhM/aE90O Ecpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711045931; x=1711650731; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=/tDVqrg38EffykSVufOJs1REUSnSjvleZCiMCsYnZFs=; b=SKC+4tDUQxQIfpk/YKCvkxWa4VNJRUoD+mPf0cI79wsJUfIF2vEnoAXNmNy7JkXteg AP5bHPUeYWuQTmj4wH7zmPFPxs6YHug7HDdVj+843ts41mk9HudPMYAbVZjP3zyUEFvI evjSopew1StJjGBSEC57necUOnenSGmsdXtUtZCHK+zDAt9CK4JxCadBwTRREOYyXj0J bQ8W9h+0PkkFMkt1vIGpZjTTOokQFEGIlLvNH7xdFPccTyXFCVNgDM+USp8eIZVXTC6I ZVWzMISp3On7H2p5jfh1b9JntpNtxZ/z3VUa0TjG2iqjzFqMh0TONPesmN/1RwSNgNg3 5lIg== X-Forwarded-Encrypted: i=1; AJvYcCUXVMcflo32XVu3qYqBT69qoi7vfq4ad8KQYJIzYvOqpFCPschQhJXWWRfrebyhURORS7JornQJsG9r/v7uWyfmYTE= X-Gm-Message-State: AOJu0YxB2850/fafbQNEWEUv3WPnzh9ssWjKibolWeeQbEzLD3zaslrx QDJoVKp/L19MI5XijJ+0SK+GpT5Q87ZV1U8dDaJoGI/uAnthtjtcmbFcVmfD0b0eXkbZZOObHsq 1AE/hqAUg7+vuQonI4w== X-Google-Smtp-Source: AGHT+IG5lSOl/jhwwB3NlG7F5mMd5seSuxnFvXu7J1mkF+F1G9gssPXELFhW/QXN70In/lrxVS3SstNQZxB3PLPX X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:29b4]) (user=yosryahmed job=sendgmr) by 2002:a0d:cac7:0:b0:60a:13b8:6a5c with SMTP id m190-20020a0dcac7000000b0060a13b86a5cmr958365ywd.0.1711045930780; Thu, 21 Mar 2024 11:32:10 -0700 (PDT) Date: Thu, 21 Mar 2024 18:32:08 +0000 In-Reply-To: Mime-Version: 1.0 References: <01b0b8e8-af1d-4fbe-951e-278e882283fd@linux.dev> Message-ID: Subject: Re: [External] Re: [bug report] mm/zswap :memory corruption after zswap_load(). From: Yosry Ahmed To: Nhat Pham Cc: Chengming Zhou , Zhongkun He , Johannes Weiner , Andrew Morton , linux-mm , wuyun.abel@bytedance.com, zhouchengming@bytedance.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: BC8DEC001F X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 89hrjjbx3r36yh8w99fb1ya1nkeijkth X-HE-Tag: 1711045931-743484 X-HE-Meta: U2FsdGVkX19at7WNtXMAZPKeRnPIbcn4yscXBWLrmyzZ863/xbog9psp2dZak8fWY+2BFk4BXUyTLWrn5ijWspIE9+eyWIFc2KHqJBFdyV5E4OXxTXm2pBu1lOgoTlKrXeBm8Ze5IatUB/maiDXBYRjyXTTSDOB+geZFR/r6IDTC0wBBAuNXYUE7ryUGvhgi4tDSq2XXaO1sp+/qO9xRWpNedu9IK1SkBdltERmOuDLz9q3/k1j677vn04SKoYuTKefQN3Fkv6e609SN10iaOd3um5e+CT5htaW29O73lWD4ydC8+yXHqh9JJ4rZ6haWI8bMnUyRG6fxUB0+URh2olHNgZKXm6J78WDLHSVsbO21q9bm30eXjnV/+dkRv2nYmSbNu3MeToUk6XmaQcibzsE6HEUTflyc9BE/UQSaAUhGTxi5SSqbBReWG9SxgkFxEL+S8hZmys/YB++ZpxrJy9mnhHYdB0BD+cVvnuUk3q0C3/79psaeLoaLox41Fpnz3+bQ4cY0omSvOF4r3QtRZ0gYkonfPDLik/DSCVOjNa+wG32ZEHNrTSLDsiot5LEFNmlXgC20xAuRtYN068Du7cgCPk4Q7ujpXa7UBfAkxxXwihzztuDcUCHNisgWGjqSflzbrMP5je/rYjo48WLOktS8JMfS9S8umYxZwow4ZtcEonK4yh8mV63SqNW9rGuhiDwXTXcUPj8+/2nQLsjm7dRzHBB1VCDLnHIv1Q782sGNle8Wmf/s8eWX8MDIot2q0xfpfwHLSyiOzJLkJQy3AUb4Genkck4NRdYajLy7pv16kinMNq924aGwqLBWiN6qra6rry4gswM29gmowturXG8AuKDBTVrx870ZEDNz3SsIcohZPifs83TGR0853T/wiaTXbpjV7RHQXQiNrTr2OH5v+VXbL8AB8AieYMSDV5wATxZ47s0USAJF0W/sBd5BSxc0a0+F68WDxcT7fQa 721Ndo88 LziXABuw8vPs/7hdqJ4iKdPxzNuVqKGj0UPeZ3PEzlXy6ilsWZUfPcg3bO2neHYrQp6dCgjr4MRBSeKEKemTxlOF9YpH5lnND9A/VM43YA/lermCuzFTCTLvneXz8xebjX3011jDUFv80v9wXH0ndQg2LNSjFzCh9XPBlYs9TT1jOLYsgcapyJgJ7g71zPLMEWwErmjBvIUMbfftw/4DkKsn3zmJVBcuFjNVftqDOofjiaVBJikOoVGl9BKUqHhgH+2WHsj2tcA6W50MTfxdPDCkXZSfrTrG6jNsIMOUpmnr9QjJ02jLja+3DRE4tjnqTPDfsCbm/7UF4pmI9Mh7YoPkkFb55iu3DQvPtuuyRv/FHq0fg2zCVm8eolhXHaWW2YbKZAOcX0KGeXHfJUv4zq0IZh2OoU0zIQHrpNUzPOQXYUqfTJZDSSjRPOcID5ofMYlvaZMkKg3tVUnyyTosr8xyaFwc56Ix9Eb4nFvdepMpaDEXgReWZ1W2ddh6aBbx//KSGGvA8WSnKAmYo1eTIlqev8GcA5BYAgrN0cFKPfCjxVpqRGAv1X8ur2UmnYJ0DTd9TN2FqpyN83mXOXXjmITFaK819Smvd0Xz/Pps2kdDaXQrY4cpkmE82OS0MuquMGa8/K85toXVv0NFXaw9DAJBH+NCq4xJnNztsJK+0BMKT5ZA9SPgs40lEYJ6r07saMm13IF4rQy9ORnq9vQPQ8Xp1mP26EfVh3x8m X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Mar 21, 2024 at 08:25:26AM -0700, Nhat Pham wrote: > On Thu, Mar 21, 2024 at 2:28=E2=80=AFAM Chengming Zhou wrote: > > > > On 2024/3/21 14:36, Zhongkun He wrote: > > > On Thu, Mar 21, 2024 at 1:24=E2=80=AFPM Chengming Zhou wrote: > > >> > > >> On 2024/3/21 13:09, Zhongkun He wrote: > > >>> On Thu, Mar 21, 2024 at 12:42=E2=80=AFPM Chengming Zhou > > >>> wrote: > > >>>> > > >>>> On 2024/3/21 12:34, Zhongkun He wrote: > > >>>>> Hey folks, > > >>>>> > > >>>>> Recently, I tested the zswap with memory reclaiming in the mainli= ne > > >>>>> (6.8) and found a memory corruption issue related to exclusive lo= ads. > > >>>> > > >>>> Is this fix included? 13ddaf26be32 ("mm/swap: fix race when skippi= ng swapcache") > > >>>> This fix avoids concurrent swapin using the same swap entry. > > >>>> > > >>> > > >>> Yes, This fix avoids concurrent swapin from different cpu, but the > > >>> reported issue occurs > > >>> on the same cpu. > > >> > > >> I think you may misunderstand the race description in this fix chang= elog, > > >> the CPU0 and CPU1 just mean two concurrent threads, not real two CPU= s. > > >> > > >> Could you verify if the problem still exists with this fix? > > > > > > Yes=EF=BC=8CI'm sure the problem still exists with this patch. > > > There is some debug info, not mainline. > > > > > > bpftrace -e'k:swap_readpage {printf("%lld, %lld,%ld,%ld,%ld\n%s", > > > ((struct page *)arg0)->private,nsecs,tid,pid,cpu,kstack)}' --include > > > linux/mm_types.h > > > > Ok, this problem seems only happen on SWP_SYNCHRONOUS_IO swap backends, > > which now include zram, ramdisk, pmem, nvdimm. > > > > It maybe not good to use zswap on these swap backends? >=20 > My gut reaction is to say yes, but I'll refrain from making sweeping > statements about backends I'm not too familiar with. Let's see: >=20 > 1. zram: I don't even know why we're putting a compressed cache... in > front of a compressed faux swap device? Ramdisk =3D=3D other in-memory > swap backend right? I personally use it for testing because it's easy, but I doubt any prod setups actually do that. That being said, I don't think we need to disable zswap completely for these swap backends just to address this bug. > 2. I looked it up, and it seemed SWP_SYNCHRONOUS_IO was introduced for > fast swap storage (see the original patch series [1]). If this is the > case, one could argue there are diminishing returns for applying zswap > on top of this. >=20 > [1]: https://lore.kernel.org/linux-mm/1505886205-9671-1-git-send-email-mi= nchan@kernel.org/ >=20 > > > > The problem here is the page fault handler tries to skip swapcache to > > swapin the folio (swap entry count =3D=3D 1), but then it can't install= folio > > to pte entry since some changes happened such as concurrent fork of ent= ry. > > > > Maybe we should writeback that folio in this special case. >=20 > But yes, if this is simple maybe we can do this first to fix the bug? Can we just enforce using the swapcache if zswap is in-use? We cannot simply check if zswap is enabled, because it could be the case that we stored some pages into zswap then disabled it. Perhaps we could keep track of whether zswap was ever enabled or if any pages were ever stored in zswap, and skip the no swap cache optimization then?