linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miaohe Lin <linmiaohe@huawei.com>
To: <akpm@linux-foundation.org>, <hughd@google.com>
Cc: <willy@infradead.org>, <vbabka@suse.cz>, <dhowells@redhat.com>,
	<neilb@suse.de>, <apopple@nvidia.com>, <david@redhat.com>,
	<surenb@google.com>, <peterx@redhat.com>, <rcampbell@nvidia.com>,
	<naoya.horiguchi@nec.com>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>, <linmiaohe@huawei.com>
Subject: [PATCH v4 4/5] mm/shmem: fix infinite loop when swap in shmem error at swapoff time
Date: Thu, 19 May 2022 20:50:29 +0800	[thread overview]
Message-ID: <20220519125030.21486-5-linmiaohe@huawei.com> (raw)
In-Reply-To: <20220519125030.21486-1-linmiaohe@huawei.com>

When swap in shmem error at swapoff time, there would be a infinite loop
in the while loop in shmem_unuse_inode(). It's because swapin error is
deliberately ignored now and thus info->swapped will never reach 0. So
we can't escape the loop in shmem_unuse().

In order to fix the issue, swapin_error entry is stored in the mapping
when swapin error occurs. So the swapcache page can be freed and the
user won't end up with a permanently mounted swap because a sector is
bad. If the page is accessed later, the user process will be killed
so that corrupted data is never consumed. On the other hand, if the
page is never accessed, the user won't even notice it.

Reported-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
---
 mm/shmem.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/mm/shmem.c b/mm/shmem.c
index d3c7970e0179..d55dd972023a 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1175,6 +1175,10 @@ static int shmem_find_swap_entries(struct address_space *mapping,
 			continue;
 
 		entry = radix_to_swp_entry(folio);
+		/*
+		 * swapin error entries can be found in the mapping. But they're
+		 * deliberately ignored here as we've done everything we can do.
+		 */
 		if (swp_type(entry) != type)
 			continue;
 
@@ -1672,6 +1676,36 @@ static int shmem_replace_page(struct page **pagep, gfp_t gfp,
 	return error;
 }
 
+static void shmem_set_folio_swapin_error(struct inode *inode, pgoff_t index,
+					 struct folio *folio, swp_entry_t swap)
+{
+	struct address_space *mapping = inode->i_mapping;
+	struct shmem_inode_info *info = SHMEM_I(inode);
+	swp_entry_t swapin_error;
+	void *old;
+
+	swapin_error = make_swapin_error_entry(&folio->page);
+	old = xa_cmpxchg_irq(&mapping->i_pages, index,
+			     swp_to_radix_entry(swap),
+			     swp_to_radix_entry(swapin_error), 0);
+	if (old != swp_to_radix_entry(swap))
+		return;
+
+	folio_wait_writeback(folio);
+	delete_from_swap_cache(&folio->page);
+	spin_lock_irq(&info->lock);
+	/*
+	 * Don't treat swapin error folio as alloced. Otherwise inode->i_blocks won't
+	 * be 0 when inode is released and thus trigger WARN_ON(inode->i_blocks) in
+	 * shmem_evict_inode.
+	 */
+	info->alloced--;
+	info->swapped--;
+	shmem_recalc_inode(inode);
+	spin_unlock_irq(&info->lock);
+	swap_free(swap);
+}
+
 /*
  * Swap in the page pointed to by *pagep.
  * Caller has to make sure that *pagep contains a valid swapped page.
@@ -1695,6 +1729,9 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
 	swap = radix_to_swp_entry(*foliop);
 	*foliop = NULL;
 
+	if (is_swapin_error_entry(swap))
+		return -EIO;
+
 	/* Look it up and read it in.. */
 	page = lookup_swap_cache(swap, NULL, 0);
 	if (!page) {
@@ -1762,6 +1799,8 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
 failed:
 	if (!shmem_confirm_swap(mapping, index, swap))
 		error = -EEXIST;
+	if (error == -EIO)
+		shmem_set_folio_swapin_error(inode, index, folio, swap);
 unlock:
 	if (folio) {
 		folio_unlock(folio);
-- 
2.23.0


  parent reply	other threads:[~2022-05-19 12:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-19 12:50 [PATCH v4 0/5] A few fixup patches for mm Miaohe Lin
2022-05-19 12:50 ` [PATCH v4 1/5] mm/swapfile: unuse_pte can map random data if swap read fails Miaohe Lin
2022-05-19 12:50 ` [PATCH v4 2/5] mm/swapfile: Fix lost swap bits in unuse_pte() Miaohe Lin
2022-05-19 12:50 ` [PATCH v4 3/5] mm/madvise: free hwpoison and swapin error entry in madvise_free_pte_range Miaohe Lin
2022-05-19 12:50 ` Miaohe Lin [this message]
2022-05-20  6:34   ` [PATCH v4 4/5] mm/shmem: fix infinite loop when swap in shmem error at swapoff time HORIGUCHI NAOYA(堀口 直也)
2022-05-20  8:17     ` Miaohe Lin
2022-05-22 23:53       ` HORIGUCHI NAOYA(堀口 直也)
2022-05-23  3:01         ` Miaohe Lin
2022-05-23 11:23           ` Miaohe Lin
2022-05-24  6:44             ` HORIGUCHI NAOYA(堀口 直也)
2022-05-24 10:56               ` Miaohe Lin
2022-05-21  9:34     ` Miaohe Lin
2022-05-24 22:10       ` Andrew Morton
2022-05-25  1:42         ` Miaohe Lin
2022-05-25  4:32   ` HORIGUCHI NAOYA(堀口 直也)
2022-05-25  6:40     ` Miaohe Lin
2022-05-26  6:08       ` HORIGUCHI NAOYA(堀口 直也)
2022-05-19 12:50 ` [PATCH v4 5/5] mm: filter out swapin error entry in shmem mapping Miaohe Lin
2022-05-25  4:53   ` HORIGUCHI NAOYA(堀口 直也)

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=20220519125030.21486-5-linmiaohe@huawei.com \
    --to=linmiaohe@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=david@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=neilb@suse.de \
    --cc=peterx@redhat.com \
    --cc=rcampbell@nvidia.com \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).