Re: [PATCH 2/4] mm/memory-failure.c: fix wrong user reference report

[HORIGUCHI NAOYA(堀口 直也)]

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)?

I'm trying to test hwpoison hitting the dirty swapcache, but it seems that
in my testing memory_faliure() fails with "hwpoison: unhandlable page"
warning at get_any_page().  So I'm still not sure that me_pagecache_dirty()
fixes any visible problem.

Thanks,
Naoya Horiguchi

> 
> Signed-off-by: Miaohe Lin <linmiaohe@xxxxxxxxxx>
> ---
>  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