linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miaohe Lin <linmiaohe@huawei.com>
To: "HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/4] mm/memory-failure.c: fix wrong user reference report
Date: Mon, 7 Mar 2022 19:26:22 +0800	[thread overview]
Message-ID: <227af111-9264-02fd-9e46-744d39ecfed0@huawei.com> (raw)
In-Reply-To: <20220304082714.GB3778609@hori.linux.bs1.fc.nec.co.jp>

On 2022/3/4 16:27, HORIGUCHI NAOYA(堀口 直也) wrote:
> On Mon, Feb 28, 2022 at 10:02:43PM +0800, Miaohe Lin wrote:
>> The dirty swapcache page is still residing in the swap cache after it's
>> hwpoisoned. So there is always one extra refcount for swap cache.
> 
> The diff seems fine at a glance, but let me have a few question to
> understand the issue more.
> 
> - Is the behavior described above the effect of recent change on shmem where
>   dirty pagecache is pinned on hwpoison (commit a76054266661 ("mm: shmem:
>   don't truncate page if memory failure happens"). Or the older kernels
>   behave as the same?
> 
> - Is the behavior true for normal anonymous pages (not shmem pages)?
> 

The behavior described above is aimed at swapcache not pagecache. So it should be
irrelevant with the recent change on shmem.

What I try to fix here is that me_swapcache_dirty holds one extra pin via SwapCache
regardless of the return value of delete_from_lru_cache. We should try to report more
accurate extra refcount for debugging purpose.

> I'm trying to test hwpoison hitting the dirty swapcache, but it seems that
> in my testing memory_faliure() fails with "hwpoison: unhandlable page"

Maybe memory_faliure is racing with page reclaim where page is isolated?

> warning at get_any_page().  So I'm still not sure that me_pagecache_dirty()
> fixes any visible problem.

IIUC, me_pagecache_dirty can't do much except for the corresponding address_space supporting
error_remove_page which can truncate the dirty pagecache page. But this may cause silent data
loss. It's better to keep the page stay in the pagecache until the file is truncated, hole
punched or removed as commit a76054266661 pointed out.

Thanks.

> > Thanks,
> Naoya Horiguchi
> 
>>
>> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
>> ---
>>  mm/memory-failure.c | 6 +-----
>>  1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index 0d7c58340a98..5f9503573263 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -984,7 +984,6 @@ static int me_pagecache_dirty(struct page_state *ps, struct page *p)
>>  static int me_swapcache_dirty(struct page_state *ps, struct page *p)
>>  {
>>  	int ret;
>> -	bool extra_pins = false;
>>  
>>  	ClearPageDirty(p);
>>  	/* Trigger EIO in shmem: */
>> @@ -993,10 +992,7 @@ static int me_swapcache_dirty(struct page_state *ps, struct page *p)
>>  	ret = delete_from_lru_cache(p) ? MF_FAILED : MF_DELAYED;
>>  	unlock_page(p);
>>  
>> -	if (ret == MF_DELAYED)
>> -		extra_pins = true;
>> -
>> -	if (has_extra_refcount(ps, p, extra_pins))
>> +	if (has_extra_refcount(ps, p, true))
>>  		ret = MF_FAILED;
>>  
>>  	return ret;
>> -- 
>> 2.23.0


  reply	other threads:[~2022-03-07 11:31 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 14:02 [PATCH 0/4] A few fixup patches for memory failure Miaohe Lin
2022-02-28 14:02 ` [PATCH 1/4] mm/memory-failure.c: fix race with changing page compound again Miaohe Lin
2022-03-04  8:26   ` HORIGUCHI NAOYA(堀口 直也)
2022-03-04 19:32     ` Mike Kravetz
2022-03-07  3:44       ` Miaohe Lin
2022-03-07  7:01         ` HORIGUCHI NAOYA(堀口 直也)
2022-03-07 19:07           ` Mike Kravetz
2022-03-08  6:56             ` HORIGUCHI NAOYA(堀口 直也)
2022-03-08 11:28               ` Miaohe Lin
2022-02-28 14:02 ` [PATCH 2/4] mm/memory-failure.c: fix wrong user reference report Miaohe Lin
2022-03-04  8:27   ` HORIGUCHI NAOYA(堀口 直也)
2022-03-07 11:26     ` Miaohe Lin [this message]
2022-03-07 20:14       ` Yang Shi
2022-03-08 13:11         ` Miaohe Lin
2022-03-08 18:51           ` Yang Shi
2022-03-09  8:30             ` Miaohe Lin
2022-02-28 14:02 ` [PATCH 3/4] mm/memory-failure.c: avoid calling invalidate_inode_page() with unexpected pages Miaohe Lin
2022-02-28 14:02 ` [PATCH 4/4] mm/memory-failure.c: fix potential VM_BUG_ON_PAGE in split_huge_page_to_list Miaohe Lin
2022-03-04  8:28   ` HORIGUCHI NAOYA(堀口 直也)
2022-03-07  7:07     ` Miaohe Lin
2022-03-07 19:53       ` Yang Shi
2022-03-08 12:36         ` Miaohe Lin
2022-03-08 18:47           ` Yang Shi
2022-03-09  8:45             ` Miaohe Lin
2022-03-10 11:46             ` Miaohe Lin
2022-03-10 19:32               ` Yang Shi
2022-03-11  1:54                 ` Miaohe Lin

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=227af111-9264-02fd-9e46-744d39ecfed0@huawei.com \
    --to=linmiaohe@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=naoya.horiguchi@nec.com \
    /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).