All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miaohe Lin <linmiaohe@huawei.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Shiyang Ruan <ruansy.fnst@fujitsu.com>,
	Christoph Hellwig <hch@lst.de>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Dave Chinner <david@fromorbit.com>,
	Goldwyn Rodrigues <rgoldwyn@suse.de>,
	Jane Chu <jane.chu@oracle.com>,
	Matthew Wilcox <willy@infradead.org>,
	Ritesh Harjani <riteshh@linux.ibm.com>, <nvdimm@lists.linux.dev>,
	<linux-xfs@vger.kernel.org>, <linux-mm@kvack.org>,
	<linux-fsdevel@vger.kernel.org>, <akpm@linux-foundation.org>,
	<djwong@kernel.org>
Subject: Re: [PATCH 4/4] mm/memory-failure: Fall back to vma_address() when ->notify_failure() fails
Date: Tue, 30 Aug 2022 11:30:21 +0800	[thread overview]
Message-ID: <76fb4464-73eb-256c-60e0-a0c3dc152e78@huawei.com> (raw)
In-Reply-To: <166153429427.2758201.14605968329933175594.stgit@dwillia2-xfh.jf.intel.com>

On 2022/8/27 1:18, Dan Williams wrote:
> In the case where a filesystem is polled to take over the memory failure
> and receives -EOPNOTSUPP it indicates that page->index and page->mapping
> are valid for reverse mapping the failure address. Introduce
> FSDAX_INVALID_PGOFF to distinguish when add_to_kill() is being called
> from mf_dax_kill_procs() by a filesytem vs the typical memory_failure()
> path.

Thanks for fixing.
I'm sorry but I can't find the bug report email. Do you mean mf_dax_kill_procs() can
pass an invalid pgoff to the add_to_kill()? But it seems pgoff is guarded against invalid
value by vma_interval_tree_foreach() in collect_procs_fsdax(). So pgoff should be an valid
value. Or am I miss something?

Thanks,
Miaohe Lin

> 
> Otherwise, vma_pgoff_address() is called with an invalid fsdax_pgoff
> which then trips this failing signature:
> 
>  kernel BUG at mm/memory-failure.c:319!
>  invalid opcode: 0000 [#1] PREEMPT SMP PTI
>  CPU: 13 PID: 1262 Comm: dax-pmd Tainted: G           OE    N 6.0.0-rc2+ #62
>  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
>  RIP: 0010:add_to_kill.cold+0x19d/0x209
>  [..]
>  Call Trace:
>   <TASK>
>   collect_procs.part.0+0x2c4/0x460
>   memory_failure+0x71b/0xba0
>   ? _printk+0x58/0x73
>   do_madvise.part.0.cold+0xaf/0xc5
> 
> Fixes: c36e20249571 ("mm: introduce mf_dax_kill_procs() for fsdax case")
> Cc: Shiyang Ruan <ruansy.fnst@fujitsu.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Darrick J. Wong <djwong@kernel.org>
> Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Dave Chinner <david@fromorbit.com>
> Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>
> Cc: Jane Chu <jane.chu@oracle.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Miaohe Lin <linmiaohe@huawei.com>
> Cc: Ritesh Harjani <riteshh@linux.ibm.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  mm/memory-failure.c |   22 ++++++++++++----------
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 8a4294afbfa0..e424a9dac749 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -345,13 +345,17 @@ static unsigned long dev_pagemap_mapping_shift(struct vm_area_struct *vma,
>   * not much we can do.	We just print a message and ignore otherwise.
>   */
>  
> +#define FSDAX_INVALID_PGOFF ULONG_MAX
> +
>  /*
>   * Schedule a process for later kill.
>   * Uses GFP_ATOMIC allocations to avoid potential recursions in the VM.
>   *
> - * Notice: @fsdax_pgoff is used only when @p is a fsdax page.
> - *   In other cases, such as anonymous and file-backend page, the address to be
> - *   killed can be caculated by @p itself.
> + * Note: @fsdax_pgoff is used only when @p is a fsdax page and a
> + * filesystem with a memory failure handler has claimed the
> + * memory_failure event. In all other cases, page->index and
> + * page->mapping are sufficient for mapping the page back to its
> + * corresponding user virtual address.
>   */
>  static void add_to_kill(struct task_struct *tsk, struct page *p,
>  			pgoff_t fsdax_pgoff, struct vm_area_struct *vma,
> @@ -367,11 +371,7 @@ static void add_to_kill(struct task_struct *tsk, struct page *p,
>  
>  	tk->addr = page_address_in_vma(p, vma);
>  	if (is_zone_device_page(p)) {
> -		/*
> -		 * Since page->mapping is not used for fsdax, we need
> -		 * calculate the address based on the vma.
> -		 */
> -		if (p->pgmap->type == MEMORY_DEVICE_FS_DAX)
> +		if (fsdax_pgoff != FSDAX_INVALID_PGOFF)
>  			tk->addr = vma_pgoff_address(fsdax_pgoff, 1, vma);
>  		tk->size_shift = dev_pagemap_mapping_shift(vma, tk->addr);
>  	} else
> @@ -523,7 +523,8 @@ static void collect_procs_anon(struct page *page, struct list_head *to_kill,
>  			if (!page_mapped_in_vma(page, vma))
>  				continue;
>  			if (vma->vm_mm == t->mm)
> -				add_to_kill(t, page, 0, vma, to_kill);
> +				add_to_kill(t, page, FSDAX_INVALID_PGOFF, vma,
> +					    to_kill);
>  		}
>  	}
>  	read_unlock(&tasklist_lock);
> @@ -559,7 +560,8 @@ static void collect_procs_file(struct page *page, struct list_head *to_kill,
>  			 * to be informed of all such data corruptions.
>  			 */
>  			if (vma->vm_mm == t->mm)
> -				add_to_kill(t, page, 0, vma, to_kill);
> +				add_to_kill(t, page, FSDAX_INVALID_PGOFF, vma,
> +					    to_kill);
>  		}
>  	}
>  	read_unlock(&tasklist_lock);
> 
> 
> .
> 


  parent reply	other threads:[~2022-08-30  3:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 17:17 [PATCH 0/4] mm, xfs, dax: Fixes for memory_failure() handling Dan Williams
2022-08-26 17:17 ` [PATCH 1/4] xfs: Quiet notify_failure EOPNOTSUPP cases Dan Williams
2022-09-05 14:42   ` Christoph Hellwig
2022-08-26 17:18 ` [PATCH 2/4] xfs: Fix SB_BORN check in xfs_dax_notify_failure() Dan Williams
2022-09-05 14:44   ` Christoph Hellwig
2022-08-26 17:18 ` [PATCH 3/4] mm/memory-failure: Fix detection of memory_failure() handlers Dan Williams
2022-08-29  5:39   ` HORIGUCHI NAOYA(堀口 直也)
2022-08-30  2:49   ` Miaohe Lin
2022-09-05 14:45   ` Christoph Hellwig
2022-08-26 17:18 ` [PATCH 4/4] mm/memory-failure: Fall back to vma_address() when ->notify_failure() fails Dan Williams
2022-08-29  5:42   ` HORIGUCHI NAOYA(堀口 直也)
2022-08-30  3:30   ` Miaohe Lin [this message]
2022-08-30  3:57     ` Dan Williams
2022-08-30  6:17       ` Miaohe Lin
2022-09-05 14:45   ` Christoph Hellwig

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=76fb4464-73eb-256c-60e0-a0c3dc152e78@huawei.com \
    --to=linmiaohe@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=jane.chu@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=nvdimm@lists.linux.dev \
    --cc=rgoldwyn@suse.de \
    --cc=riteshh@linux.ibm.com \
    --cc=ruansy.fnst@fujitsu.com \
    --cc=viro@zeniv.linux.org.uk \
    --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.