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 BA685C021B2 for ; Sat, 22 Feb 2025 08:03:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E81D6B007B; Sat, 22 Feb 2025 03:03:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 09C026B0083; Sat, 22 Feb 2025 03:03:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7B086B0085; Sat, 22 Feb 2025 03:03:06 -0500 (EST) 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 C82C66B007B for ; Sat, 22 Feb 2025 03:03:06 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 500CB1209B0 for ; Sat, 22 Feb 2025 08:03:06 +0000 (UTC) X-FDA: 83146839972.14.3BF3021 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf01.hostedemail.com (Postfix) with ESMTP id 5003340013 for ; Sat, 22 Feb 2025 08:03:04 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HvSVQvgW; spf=pass (imf01.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740211384; a=rsa-sha256; cv=none; b=M8DHo5RgAqCzoq/+IsQse3WjT+838h31fGZhgZR+nfxAyT5RsUvu598yojI1bvHWJEyWNC sxs7oN9cTIDdKlIuvB6jKSQim9kByFbNXful80B2A/ZA8IZBhnBU+eQk8eaRj0hRcBH+2x ZmHmV5GdTdBeOPMgxTU5Q7Gphd431t4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HvSVQvgW; spf=pass (imf01.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740211384; 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=7Os2fsuEkFh0JKJmUAnJvJ3YM3Zu/tIQHYWk9O1cYrw=; b=4TjTxwU2ge0G+fCu8HJnpXSidsF/NT843IGOE+w0dEVgmfPwVhPw9/gmMN1YhBPeb7LPKK 1dTHVg/vQ7VeNgDxfveRzNXWF4WAhDjP9Wix7xfEhs1gj5bbdxgLBQWNiKKA3xKyabo/Tn GZkIgv5MUtmP5orTM2Jykw4FO9laYXA= Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-545fed4642aso2812915e87.0 for ; Sat, 22 Feb 2025 00:03:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740211382; x=1740816182; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7Os2fsuEkFh0JKJmUAnJvJ3YM3Zu/tIQHYWk9O1cYrw=; b=HvSVQvgWLsGGGfu4r+vOCfkI/x7TwI16mQPzbnM90roXSW9eFlaWgRUA3Ik4tddAAc /GqkGn3nLZtekD1O7xskyfnZzKMSKgfroBTBGAkhIwSCNacSFy9WcQ5VRl9/ZRQCq6EK 3rsa7jyqX8w11XXRaZvlGqijp5rTv62zgZT8szSblLFS0a5BzPSDHxmGF/Egv+ZYv3iI 6ux9BaAKhNBCpgxYey1lRf4ryO4XNkjfCSqpMV7S4SRSfEkr3QwSgpAAMW6rWt6dn8fj s9AQDQGap/hBirxFG8eSlOtz6Klc4+9nT8ERMrSzC3QQPEHhSB00p1BUthgrZsuUvXoI Yk7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740211382; x=1740816182; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7Os2fsuEkFh0JKJmUAnJvJ3YM3Zu/tIQHYWk9O1cYrw=; b=O04O8+HffDykUc+dh1yvXTcCuBgbOZgMKEm9f6jmkqj0jo/n/2TNUobJXp4d3SWmYw QPiuUYPC1ZbJjlkI0PrgLUlZVVoubX4aZQdu+a78YuTTpanmiia4vhhkSYCNMgi/Fkij biU8OgAz/fbM58Y4PPnhS6NiBmbgiq5FZr3Czqr3GWirFlVxKfOlFpPOx5ZPair5Sicr 0ijlVJzkdU8dHCYW6EtiVbJI4ozpZYM/93wf/5IFo1OQuF1JbiM3tL9OwsXIQCub8U4F x84fEJy9gnF+x5yp0S2Xzk1S3gzY8RDhTzzHP5AbN2bQwUDg0oNSZ5LzRJ8aSwXO/Qty PUBQ== X-Forwarded-Encrypted: i=1; AJvYcCU5UzETusIb2AZ2PE0o7z81IhHFS9uqy/wBNbpjV79ax4+NU35pyepuBJtrnOFs9r4lmlIhqdts0w==@kvack.org X-Gm-Message-State: AOJu0YzVCe8MKPpHLvrrleFlzrRqOWrDWQr4YWIJsjWTriINwaDiMSFL AK3g+jT7YPL+/xLGnLqjuBJnuWmXNtp4Mj/jCjJQc+XQPRZ5H8Uos3VXvzxpMrrQ3YxCL8KW+8D WsjekgdtwJHpfY3Sa14x2CWVV/vM= X-Gm-Gg: ASbGncuXZQ0/oVBmuggMV968JEDvDMPO8cWLC1OciIGinLrWhNUTNheRsIMxd/lrHcs MWj1AVlGe5yPlH0GRudMlRYteiNO3saVZMggexYWvCx/ZjhfzHjyIn2uxVFVTU0VQAHEmZsNFvE s6k0T2m7w= X-Google-Smtp-Source: AGHT+IFgo1h543qi0eAUe4bvaNCKelQB3okCfU4mFxeG5O+5Njw4vnQ4Au9r03h5Z157IMHeOXvZ80NjwuqpuCKzfWc= X-Received: by 2002:a05:6512:238a:b0:545:ea9:1a1e with SMTP id 2adb3069b0e04-54838ef5c21mr2474485e87.26.1740211382078; Sat, 22 Feb 2025 00:03:02 -0800 (PST) MIME-Version: 1.0 References: <20250222024617.2790609-1-mawupeng1@huawei.com> In-Reply-To: From: Kairui Song Date: Sat, 22 Feb 2025 16:02:45 +0800 X-Gm-Features: AWEUYZnLGbycxuCxyOi4UGegDEqKEvwp222_cZnWlGFTsG4Dcgo766zj7tWUEkg Message-ID: Subject: Re: [PATCH] mm: swap: Avoid infinite loop if no valid swap entry found during do_swap_page To: mawupeng Cc: akpm@linux-foundation.org, david@redhat.com, ryan.roberts@arm.com, chrisl@kernel.org, huang.ying.caritas@gmail.com, schatzberg.dan@gmail.com, baohua@kernel.org, hanchuanhua@oppo.com, willy@infradead.org, gaoxu2@honor.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, nphamcs@gmail.com, yosryahmed@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 3aqqkgj494ny4dsdu8mb3jh1iambf1nq X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5003340013 X-Rspam-User: X-HE-Tag: 1740211384-131062 X-HE-Meta: U2FsdGVkX1+slpv8oZACDxbiVaXe3g3h2etKM680Xb20BjOdqM9WlIVOmoyY7moBurj+K6jwewqw9Ra7uz7k5oWZZEGd9TgS6wbztjBZLw0PferOjWx1GTVUzcByvR82vfzbz0qcPKPEAw9CPLWwDXUUaR5j8mimDiEGOX47vlOB4ielDA1CiUYsoE4PKFdV4ThLcTr2UEVOzFUTvrPjM/C3fnmfLNCJVfxmmY1WPcIfj4Josonwlzx99D6xiDAXx1eXaES7oY8g6Ybux6tfKJ1UMDAD+4HrCTAZOq+r10lHxLRxPyB2ENtS2Sla3zMHfDrkcR0NK/wJnQc1qu+4EjrkK0a3Cf/U9pSPLz0MOCis4G4Ux1a/nMw7BUTxKRfpjb4mb+4ffh7m82mCttYxoTMUpkod0j0lW1Fw1ZgVTaOghhf/JXehQ+wR1R2mOxywwc98CWUWJjjP+LweYTZCZj5GsDWN9RIuxvSoMf02TudXpExRz1jiJ+M54O3tTyK9vSNc3SuJlgCXCBDsJAzJsPI/2azb2HtPlZulmilFfZl5fydzurM8/dN9gkPKzK5RPJtL7PDohAOR6Il8vT/JLNN9U/NGcePlUQC7/nn2A/OoD5Hqs/Z2VnEpM2aoaDTEfvfjKmpJSxuMulUoUNrkN866nSNirp0EkiwVfv50KTUyyv8GpQBzdBi5KfR/LuLjQTBQ2C/W22c2hqCnd+upnOJ7co5iigp2S0A0l5SPssuUfn6K3Zy4/BFcGdXWXlOzxLhXTgZx0P6+EfjnJLB4uMz0pTCevKpz4A7RDyATkNwHobzVm8KF72AVpKcFO5Fn3TZKwkYb+XmyZd+4n1Pc2SxMImfvPLCPuThWB2AVW1KDd17Psf+iI2uRbdgamYndSI/XKR0+C9pGanl94BPPHcWzANxu/j9bMZEe/V903pVveQI1NrhM0ECnvBA3Bn6qYbQ3dbsoBYT23NP72jp WrSt893H WBXr4wrkGzHr5TWBMW5pdrE2J5EHhu/XsWPyG/x68Kj24deMa1fomFCkpR3WE3ftf77f0xYHngomMGvzgQy0fTIvix7FGL3BoRelLN3646aCBqP4gvsLPSaWQsjVJjxHyxUVRJqxVFLAvywoH07UOCPyw4M9YGCKegLhCjUaf0Vm9TM9m50tTApHBVHclN5Ai3P2WiJZX5A41P+onloqrQQIo/oHWyQc9OZQsE+SfVN9XHrpRTRFam7wfawjvYIa0jEn2jIdTPqukpUHXOsibRIcS9CWK+t5on7KWvlaJuZK0myebqwUSY81Pq/S44k6Kk3FnJfZ7kJZmLcGmeIvlvpnuLWn/Pt4uOP7qxgttvrwd6dN3zKR9sVNxj3YePDwIEQZ/U6DelxdKCrt1a5CqOkZE5mSJlbTkR8tn7V8WVcF5ZjDwmpjcfm/29MmMWBZHoIaBADyxWlZUzRCws1al8ZdYjnvwgezmomIrdDLrD0Gi4oxPllFc4mrGFhvm4lJIPXDJfiX53gHWh0U4BsDA0N5xIB15fSAylfqD X-Bogosity: Ham, tests=bogofilter, spamicity=0.000420, 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 Sat, Feb 22, 2025 at 3:41=E2=80=AFPM mawupeng wro= te: > On 2025/2/22 15:33, Kairui Song wrote: > > On Sat, Feb 22, 2025 at 10:56=E2=80=AFAM Wupeng Ma wrote: > >> > >> From: Ma Wupeng > >> > >> During our test, infinite loop is produced during #PF will lead to inf= inite > >> error log as follow: > >> > >> get_swap_device: Bad swap file entry 114000000 > >> > >> Digging into the source, we found that the swap entry is invalid due t= o > >> unknown reason, and this lead to invalid swap_info_struct. Excessive l= og > > > > Hi Wupeng, > > > > What is the kernel version you are using? If it's another bug causing > > this invalid swap entry, we should fix that bug instead, not > > workaround it. > > > > This looks kind of similar to another PATCH & Bug report, corrupted > > page table or swap entry: > > https://lore.kernel.org/linux-mm/e223b0e6ba2f4924984b1917cc717bd5@honor= .com/ > > > > Might be the same kernel bug? Gaoxu mentioned the bug was observed on > > Kernel 6.6.30 (android version), and neither of these two workarounds > > will fix it completely, the invalid value could cause many other > > issues too. We definitely need to find out the root cause. > > We are having this problem in linux-v5.10, since the log is lost and swap > is not enabled in this machines, maybe memory corrupted in the pt. Thanks for the info, that's very strange. Since you didn't even enable SWAP, it must be something else corrupted the page table I think > > > >> printing can fill up the prioritized log space, leading to the purging= of > >> originally valid logs and hindering problem troubleshooting. To make t= his > >> more robust, kill this task. > >> > >> Signed-off-by: Ma Wupeng > >> --- > >> include/linux/swap.h | 1 + > >> mm/memory.c | 9 ++++++++- > >> mm/swapfile.c | 2 +- > >> 3 files changed, 10 insertions(+), 2 deletions(-) > >> > >> diff --git a/include/linux/swap.h b/include/linux/swap.h > >> index b13b72645db3..0fa39cf66bc4 100644 > >> --- a/include/linux/swap.h > >> +++ b/include/linux/swap.h > >> @@ -508,6 +508,7 @@ struct backing_dev_info; > >> extern int init_swap_address_space(unsigned int type, unsigned long n= r_pages); > >> extern void exit_swap_address_space(unsigned int type); > >> extern struct swap_info_struct *get_swap_device(swp_entry_t entry); > >> +struct swap_info_struct *_swap_info_get(swp_entry_t entry); > >> sector_t swap_folio_sector(struct folio *folio); > >> > >> static inline void put_swap_device(struct swap_info_struct *si) > >> diff --git a/mm/memory.c b/mm/memory.c > >> index b4d3d4893267..2d36e5a644d1 100644 > >> --- a/mm/memory.c > >> +++ b/mm/memory.c > >> @@ -4365,8 +4365,15 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > >> > >> /* Prevent swapoff from happening to us. */ > >> si =3D get_swap_device(entry); > >> - if (unlikely(!si)) > >> + if (unlikely(!si)) { > >> + if (unlikely(!_swap_info_get(entry))) > >> + /* > >> + * return VM_FAULT_SIGBUS for invalid swap ent= ry to > >> + * avoid infinite #PF. > >> + */ > >> + ret =3D VM_FAULT_SIGBUS; > > > > This could lead to VM_FAULT_SIGBUS on swapoff. After swapoff > > get_swap_device will return NULL. > > If swap is off, All swap pages should be swap in as expected, so > such entry can not trigger do_swap_page? do_swap_page may get blocked due to some random reason, and then a concurrent swapoff could swap in the entry and disable the device. Very unlikely to trigger but in theory possible.