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 A3A4CC021B2 for ; Sat, 22 Feb 2025 09:58:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C68DE6B007B; Sat, 22 Feb 2025 04:58:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BF1946B0083; Sat, 22 Feb 2025 04:58:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A92056B0085; Sat, 22 Feb 2025 04:58:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 876596B007B for ; Sat, 22 Feb 2025 04:58:25 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 355EC120EE4 for ; Sat, 22 Feb 2025 09:58:25 +0000 (UTC) X-FDA: 83147130570.27.B9E512F Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) by imf26.hostedemail.com (Postfix) with ESMTP id 46736140007 for ; Sat, 22 Feb 2025 09:58:23 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.42 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=quarantine) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740218303; 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; bh=miMTL+Ibz2ZHlrxtRz9K3mZRlvBnkZQuM5tmX7QkF0c=; b=6lFZ+NPY8gSDABx7BMP/ZaQvO8tskK3t4k14adyM/gCD+aDHXS6JM1lsrTaIV95mwkj0Kc bcgicdm0+QBHiJNYp9XSbk9i5qppBhhITuC6NeE/xOr3+25vNBfYsarp7TIsL11pXSY4pV WCyoem34y34nHq9dkIu3lg8+7vTycqQ= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.42 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=quarantine) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740218303; a=rsa-sha256; cv=none; b=OreoGcs7rrELw978P/JRr2mFeG6KMHsnS3UgbtwfUpprgH85ft9nqILehGReKqeDNp2q54 7vy1M7FDt6RBnXf+f5WmWCXD21y0yelSS/3r5RnhOFL5dVPXO91gxK2QG3q5UrQaxV1imW JuTcDgugvsPJywtss5A6M+55HTxIHao= Received: by mail-vs1-f42.google.com with SMTP id ada2fe7eead31-4b68cb2abacso871230137.3 for ; Sat, 22 Feb 2025 01:58:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740218302; x=1740823102; 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=miMTL+Ibz2ZHlrxtRz9K3mZRlvBnkZQuM5tmX7QkF0c=; b=fDGUi5ZFXpVJCUm75kGZGt9AP/p6hiWgcF+33EhhyU0WyEDBT5JgQ9PYfh5oLjML0d OUKdWvA8sGzq5wE7p87/46KLlpeQyFVxfYwefoqj074y5pHED8MAjw1Qwex7qPKdEN9W I+wipwKdOpU5sJxf7yij8Lm+3TS/H+MLAqKezjvh4Ep5CCI494IJwpbOYOiaDf7BOf/t 6+3Mf0bj6aP3zs16N/hgwXLKvZY6oL2mDmKp52UInnz/r3PtTpdxsjAJEAYwLyey1kv4 sSDtOwcYVeCTe/rQuiFU/R1oQkrCGWHk0NWG7TjoJSZ5mH4doU4h4GEmum0pQjT3ghIH Nvsg== X-Forwarded-Encrypted: i=1; AJvYcCUQ6jHHNmixGX7etBJfnbtHfkTI0Sa5TNT/u+IC0RvEFafU77UzUsse+Sk1rOX6LZ1Y6TKMpGbDHA==@kvack.org X-Gm-Message-State: AOJu0Ywq1hgpfXMmZwggc/yz64uHVGTpsZFyetV1Y91GvgqXsaeAl8Ku 56ZPom/qprYoZdBV5EOVTj7fA1wrmNqgN6fXJIPwfpvtBg5GRo/oV6To1+9DpMrxXV/WPeOuki0 LC/nhMRapvOyf0WmungzmvaGi17A= X-Gm-Gg: ASbGncsJO6uF5+ABScwebwdCMclRtws6SqK2mW7bNBLt35sZuVuAGRia/f++s9bqZo1 CCrubOuR7qONaeJkTIu8xqJ7gQwDiucwjtSXHHxzEcw2T0cawSVgdIEVsAl3BBU4EgBu4jicfu/ qxplSJWDE= X-Google-Smtp-Source: AGHT+IH862+3snHiTNiHtpiNOaVebF10wLzPZDhja6mB2OdnLByqTrRDd9lQn502Dky8M/LD1mFJ7ahBqOc3/0wE0U0= X-Received: by 2002:a05:6102:dc6:b0:4bb:b868:9d2d with SMTP id ada2fe7eead31-4bfc028c564mr3923572137.24.1740218302311; Sat, 22 Feb 2025 01:58:22 -0800 (PST) MIME-Version: 1.0 References: <20250222024617.2790609-1-mawupeng1@huawei.com> In-Reply-To: From: Barry Song Date: Sat, 22 Feb 2025 22:58:11 +1300 X-Gm-Features: AWEUYZkREUP02MnSFVZ9f4vjkeZNf-q9qUt0ApDtdRrJ74AE5UIIkwURMldW7Ns Message-ID: Subject: Re: [PATCH] mm: swap: Avoid infinite loop if no valid swap entry found during do_swap_page To: Kairui Song Cc: mawupeng , akpm@linux-foundation.org, david@redhat.com, ryan.roberts@arm.com, chrisl@kernel.org, huang.ying.caritas@gmail.com, schatzberg.dan@gmail.com, 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-Rspam-User: X-Rspamd-Queue-Id: 46736140007 X-Stat-Signature: z1648fd34w9jfzsn4crox9n6m354cbd9 X-Rspamd-Pre-Result: action=add header; module=dmarc; Action set by DMARC X-Rspamd-Server: rspam03 X-Rspam: Yes X-HE-Tag: 1740218303-413025 X-HE-Meta: U2FsdGVkX1/IgZABrSVUdj+olGZb5laMlJZdVrYdjO7JHuXd3rtlvJ3xIP+xqFupqFDXCf/u6/uC6ghWXyJvQ/eHVPRCwqbFqXE9QRRMPJgXISKd5Fzo+Xf+6Js4QjEL9IZLVRBxj3a4pbNaPMAbsm0wQh5zBFZcAxf5LsgH2AUp7xKCUXUrmVNKoA9ByGKgvEy73sNs+yDfOqvciGVL5xQ+fw/sjkBp2qQccE91nZmNrPw/fsqWoSKqQDe4Ysuql1DSPOKrzjZX1LLQPwxaBZ2gtMhTlL4BmUDQYT0hkiq8X4vfwVPf9e9+drraw/mp+s+EY6i4MU4yEnCSziTZ25td1HkjQfyjR6BCKijFcE7+tjs1cOuEgu3YQet7eatD9C5Q1BxY8Uc9XK3cuq3Uv4xZazVets8b4vI20nG2oBKzzeBQuJ3rK3yEQJbG3K1V01Fep3O0EY0zjYKYXZSmk0lnxDg4W69/+dW0FEiPupjo6gv1+SlGIIuatWuVqjoTCHE0bxEADoJlDfpxQ4WWgHpwmLuGjh3Z1xFaHQ/hmNrv3RWBVVDeyv85H2XXGDJ/M0Lob0g93ZlVYWGABZj6XJ5lRjJkhel7Ej7B/N0CHCpHabo44gYmfVfn3mrV7xOAsoeDBod8wp+quTaTaQLs0fvUcroN4Yl+ZK6qclaUtJ7StUBnleMbRa6HcREW9JL1drAf7ec+R8+r/0BK0OW5j51ek3glXr01oSPRRsiJqy5XQ+bTvr/xh/Xn6t3txuBjThTLAlVn/X6EJHHJ6wfSooGNG+42v4FD9wl742w0PuRvQvzV/azC4oqBbF6O5xzuPkBvV0bIf0EV3a+VlpgAiGFJ80BJISxyIUy3z3G6oeLjnKGlp/Cj0Z24S6G2p9tSSJnKTHIodrL7T2AX2Ki2qwff2S2V5sjdyg/msTIN+yxJCQ774lXyBaJGj8sF+LDeiRKhwwehxU+dFnoYU9w a9NNtTS1 NcTSuQcguWHBmG1ITE2ShVTtSjkLUPTQLWi7P9fuYrYMfaRsQXIF6ve++iCsQRa7ClmDUDZDbl7wY2KifscxYnm7IIbBIwfh4vG2oncnoiBszsEZpfE792In7bVO49lm46POyeUtRridXU33Ti88orU3m3z5pfcSdGbpMG0RsOR+gmR5Ew5umExDbDXSXJ0nDJmucOUJvtgxfVj752zvLczRAQsi8TcDyevq/ciiCUEV77FMYrJ6los6X9RtxLznFa4okH9CW3ViJgEcteRefkcRruB7mbV8/fLRTaWbUjTppJC+JvdoUT5DFrvJZ2jw/xcv3FtBb+ZeizWcZZ5ZfdLIpCcqoVsSp7dL4wXI8IcgT0ObRK3Q5f+CQBNAtUyudJhkxVnrCezDgHW1mjAVQAtBjU8bHXIP+Us9PTMdPVqkaC/TFyH/BM6NbEWN/Wk2fXd78eI2dEYfLYhM7wurx3lMGA+qbaGeljM+7daIivX/lhg0GeIzG4YorEdv0QbF7n51wUFPwmUvSFGTu+O81cpKBLg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.002682, 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 9:03=E2=80=AFPM Kairui Song wrot= e: > > On Sat, Feb 22, 2025 at 3:41=E2=80=AFPM mawupeng w= rote: > > 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 i= nfinite > > >> 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= to > > >> unknown reason, and this lead to invalid swap_info_struct. Excessive= log > > > > > > 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@hon= or.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 sw= ap > > 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 purgi= ng of > > >> originally valid logs and hindering problem troubleshooting. To make= this > > >> 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= nr_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 e= ntry 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. The "goto out" in do_swap_page() should have handled this case. If swapoff occurred before the actual swap-in began, we should have aborted the swap-in, and userspace would retry. /* Prevent swapoff from happening to us. */ si =3D get_swap_device(entry); if (unlikely(!si)) goto out; Thanks Barry