From: Christoph Hellwig <hch@lst.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: akpm@linux-foundation.org, djwong@kernel.org,
Shiyang Ruan <ruansy.fnst@fujitsu.com>,
Christoph Hellwig <hch@lst.de>, 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>,
Miaohe Lin <linmiaohe@huawei.com>,
Naoya Horiguchi <naoya.horiguchi@nec.com>,
Ritesh Harjani <riteshh@linux.ibm.com>,
nvdimm@lists.linux.dev, linux-xfs@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/4] xfs: Quiet notify_failure EOPNOTSUPP cases
Date: Mon, 5 Sep 2022 16:42:28 +0200 [thread overview]
Message-ID: <20220905144228.GA6784@lst.de> (raw)
In-Reply-To: <166153427440.2758201.6709480562966161512.stgit@dwillia2-xfh.jf.intel.com>
On Fri, Aug 26, 2022 at 10:17:54AM -0700, Dan Williams wrote:
> XFS always registers dax_holder_operations regardless of whether the
> filesystem is capable of handling the notifications. The expectation is
> that if the notify_failure handler cannot run then there are no
> scenarios where it needs to run. In other words the expected semantic is
> that page->index and page->mapping are valid for memory_failure() when
> the conditions that cause -EOPNOTSUPP in xfs_dax_notify_failure() are
> present.
>
> A fallback to the generic memory_failure() path is expected so do not
> warn when that happens.
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
next prev parent reply other threads:[~2022-09-05 14:48 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 [this message]
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
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=20220905144228.GA6784@lst.de \
--to=hch@lst.de \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=jane.chu@oracle.com \
--cc=linmiaohe@huawei.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.