All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miaohe Lin <linmiaohe@huawei.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "HORIGUCHI NAOYA (堀口 直也)" <naoya.horiguchi@nec.com>,
	"hughd@google.com" <hughd@google.com>,
	"willy@infradead.org" <willy@infradead.org>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"neilb@suse.de" <neilb@suse.de>,
	"apopple@nvidia.com" <apopple@nvidia.com>,
	"david@redhat.com" <david@redhat.com>,
	"surenb@google.com" <surenb@google.com>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"rcampbell@nvidia.com" <rcampbell@nvidia.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 4/5] mm/shmem: fix infinite loop when swap in shmem error at swapoff time
Date: Wed, 25 May 2022 09:42:51 +0800	[thread overview]
Message-ID: <4475e184-0eea-a47b-9d7b-f90a14f08048@huawei.com> (raw)
In-Reply-To: <20220524151014.4d16f01cbd1c04ef74e4db5e@linux-foundation.org>

On 2022/5/25 6:10, Andrew Morton wrote:
> On Sat, 21 May 2022 17:34:28 +0800 Miaohe Lin <linmiaohe@huawei.com> wrote:
> 
>> On 2022/5/20 14:34, HORIGUCHI NAOYA(堀口 直也) wrote:
>>> On Thu, May 19, 2022 at 08:50:29PM +0800, Miaohe Lin wrote:
>>>> 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>
>>>
>>> Hi Miaohe,
>>>
>>> Thank you for the update.  I might miss something, but I still see the same
>>> problem (I checked it on mm-everything-2022-05-19-00-03 + this patchset).
>>
>> Hi Naoya,
>> I reproduce the issue in the linux-next-next-20220520 version. And I found even if
>> I *do not inject the swapin error*, the deadloop still occurs. After investigating the
>> code for a long while, I found the root cause:
>>
>> diff --git a/mm/shmem.c b/mm/shmem.c
>> index d55dd972023a..6d23ed4d23cb 100644
>> --- a/mm/shmem.c
>> +++ b/mm/shmem.c
>> @@ -1182,7 +1182,7 @@ static int shmem_find_swap_entries(struct address_space *mapping,
>>                 if (swp_type(entry) != type)
>>                         continue;
>>
>> -               indices[ret] = xas.xa_index;
>> +               indices[ret++] = xas.xa_index;
>>                 if (!folio_batch_add(fbatch, folio))
>>                         break;
>>
>> The origin code does not increment the ret value when a folio is found. I will send a patch
>> to fix this next week. Thanks! :)
> 
> So I'm thinking that with Hugh's "mm/shmem: fix shmem folio swapoff
> hang", this patchset is now looking OK, so
> 
> mm-swapfile-unuse_pte-can-map-random-data-if-swap-read-fails.patch
> mm-swapfile-fix-lost-swap-bits-in-unuse_pte.patch
> mm-madvise-free-hwpoison-and-swapin-error-entry-in-madvise_free_pte_range.patch
> mm-shmem-fix-infinite-loop-when-swap-in-shmem-error-at-swapoff-time.patch
> mm-filter-out-swapin-error-entry-in-shmem-mapping.patch
> #
> 
> are OK for merging into mainline?

I think so. But it might be better to have Acked-by or Reviewed-by tag for [PATCH v4 4/5] first. :)

Thanks!

> .
> 


  reply	other threads:[~2022-05-25  1:42 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 ` [PATCH v4 4/5] mm/shmem: fix infinite loop when swap in shmem error at swapoff time Miaohe Lin
2022-05-20  6:34   ` 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 [this message]
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=4475e184-0eea-a47b-9d7b-f90a14f08048@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.