All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Shiyang Ruan <ruansy.fnst@fujitsu.com>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	 Linux NVDIMM <nvdimm@lists.linux.dev>,
	Linux MM <linux-mm@kvack.org>,
	 linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	david <david@fromorbit.com>,
	 Christoph Hellwig <hch@infradead.org>,
	Jane Chu <jane.chu@oracle.com>
Subject: Re: [PATCH v9 09/10] xfs: Implement ->notify_failure() for XFS
Date: Wed, 5 Jan 2022 13:17:37 -0800	[thread overview]
Message-ID: <CAPcyv4jYOvK57LqGzvZwyHo=4sEKmdAV1jgCzDw5eeCySPGS6w@mail.gmail.com> (raw)
In-Reply-To: <20220105185334.GD398655@magnolia>

On Wed, Jan 5, 2022 at 10:53 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Sun, Dec 26, 2021 at 10:34:38PM +0800, Shiyang Ruan wrote:
> > Introduce xfs_notify_failure.c to handle failure related works, such as
> > implement ->notify_failure(), register/unregister dax holder in xfs, and
> > so on.
> >
> > If the rmap feature of XFS enabled, we can query it to find files and
> > metadata which are associated with the corrupt data.  For now all we do
> > is kill processes with that file mapped into their address spaces, but
> > future patches could actually do something about corrupt metadata.
> >
> > After that, the memory failure needs to notify the processes who are
> > using those files.
> >
> > Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
> > ---
> >  fs/xfs/Makefile             |   1 +
> >  fs/xfs/xfs_buf.c            |  15 +++
> >  fs/xfs/xfs_fsops.c          |   3 +
> >  fs/xfs/xfs_mount.h          |   1 +
> >  fs/xfs/xfs_notify_failure.c | 189 ++++++++++++++++++++++++++++++++++++
> >  fs/xfs/xfs_notify_failure.h |  10 ++
> >  6 files changed, 219 insertions(+)
> >  create mode 100644 fs/xfs/xfs_notify_failure.c
> >  create mode 100644 fs/xfs/xfs_notify_failure.h
> >
> > diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile
> > index 04611a1068b4..389970b3e13b 100644
> > --- a/fs/xfs/Makefile
> > +++ b/fs/xfs/Makefile
> > @@ -84,6 +84,7 @@ xfs-y                               += xfs_aops.o \
> >                                  xfs_message.o \
> >                                  xfs_mount.o \
> >                                  xfs_mru_cache.o \
> > +                                xfs_notify_failure.o \
> >                                  xfs_pwork.o \
> >                                  xfs_reflink.o \
> >                                  xfs_stats.o \
> > diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> > index bbb0fbd34e64..d0df7604fa9e 100644
> > --- a/fs/xfs/xfs_buf.c
> > +++ b/fs/xfs/xfs_buf.c
> > @@ -19,6 +19,7 @@
> >  #include "xfs_errortag.h"
> >  #include "xfs_error.h"
> >  #include "xfs_ag.h"
> > +#include "xfs_notify_failure.h"
> >
> >  static struct kmem_cache *xfs_buf_cache;
> >
> > @@ -1892,6 +1893,8 @@ xfs_free_buftarg(
> >       list_lru_destroy(&btp->bt_lru);
> >
> >       blkdev_issue_flush(btp->bt_bdev);
> > +     if (btp->bt_daxdev)
> > +             dax_unregister_holder(btp->bt_daxdev);
> >       fs_put_dax(btp->bt_daxdev);
> >
> >       kmem_free(btp);
> > @@ -1946,6 +1949,18 @@ xfs_alloc_buftarg(
> >       btp->bt_dev =  bdev->bd_dev;
> >       btp->bt_bdev = bdev;
> >       btp->bt_daxdev = fs_dax_get_by_bdev(bdev, &btp->bt_dax_part_off);
> > +     if (btp->bt_daxdev) {
> > +             dax_write_lock(btp->bt_daxdev);
> > +             if (dax_get_holder(btp->bt_daxdev)) {
> > +                     dax_write_unlock(btp->bt_daxdev);
> > +                     xfs_err(mp, "DAX device already in use?!");
> > +                     goto error_free;
> > +             }
> > +
> > +             dax_register_holder(btp->bt_daxdev, mp,
> > +                             &xfs_dax_holder_operations);
> > +             dax_write_unlock(btp->bt_daxdev);
> > +     }
> >
> >       /*
> >        * Buffer IO error rate limiting. Limit it to no more than 10 messages
> > diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
> > index 33e26690a8c4..d4d36c5bef11 100644
> > --- a/fs/xfs/xfs_fsops.c
> > +++ b/fs/xfs/xfs_fsops.c
> > @@ -542,6 +542,9 @@ xfs_do_force_shutdown(
> >       } else if (flags & SHUTDOWN_CORRUPT_INCORE) {
> >               tag = XFS_PTAG_SHUTDOWN_CORRUPT;
> >               why = "Corruption of in-memory data";
> > +     } else if (flags & SHUTDOWN_CORRUPT_ONDISK) {
> > +             tag = XFS_PTAG_SHUTDOWN_CORRUPT;
> > +             why = "Corruption of on-disk metadata";
> >       } else {
> >               tag = XFS_PTAG_SHUTDOWN_IOERROR;
> >               why = "Metadata I/O Error";
> > diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
> > index 00720a02e761..47ff4ac53c4c 100644
> > --- a/fs/xfs/xfs_mount.h
> > +++ b/fs/xfs/xfs_mount.h
> > @@ -435,6 +435,7 @@ void xfs_do_force_shutdown(struct xfs_mount *mp, int flags, char *fname,
> >  #define SHUTDOWN_LOG_IO_ERROR        0x0002  /* write attempt to the log failed */
> >  #define SHUTDOWN_FORCE_UMOUNT        0x0004  /* shutdown from a forced unmount */
> >  #define SHUTDOWN_CORRUPT_INCORE      0x0008  /* corrupt in-memory data structures */
> > +#define SHUTDOWN_CORRUPT_ONDISK      0x0010  /* corrupt metadata on device */
> >
> >  #define XFS_SHUTDOWN_STRINGS \
> >       { SHUTDOWN_META_IO_ERROR,       "metadata_io" }, \
> > diff --git a/fs/xfs/xfs_notify_failure.c b/fs/xfs/xfs_notify_failure.c
> > new file mode 100644
> > index 000000000000..a87bd08365f4
> > --- /dev/null
> > +++ b/fs/xfs/xfs_notify_failure.c
> > @@ -0,0 +1,189 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2021 Fujitsu.  All Rights Reserved.
> > + */
> > +
> > +#include "xfs.h"
> > +#include "xfs_shared.h"
> > +#include "xfs_format.h"
> > +#include "xfs_log_format.h"
> > +#include "xfs_trans_resv.h"
> > +#include "xfs_mount.h"
> > +#include "xfs_alloc.h"
> > +#include "xfs_bit.h"
> > +#include "xfs_btree.h"
> > +#include "xfs_inode.h"
> > +#include "xfs_icache.h"
> > +#include "xfs_rmap.h"
> > +#include "xfs_rmap_btree.h"
> > +#include "xfs_rtalloc.h"
> > +#include "xfs_trans.h"
> > +
> > +#include <linux/mm.h>
> > +#include <linux/dax.h>
> > +
> > +struct failure_info {
> > +     xfs_agblock_t           startblock;
> > +     xfs_filblks_t           blockcount;
> > +     int                     mf_flags;
>
> Why is blockcount a 64-bit quantity, when the failure information is
> dealt with on a per-AG basis?  I think "xfs_extlen_t blockcount" should
> be large enough here.  (I'll get back to this further down.)
>
> > +};
> > +
> > +static pgoff_t
> > +xfs_failure_pgoff(
> > +     struct xfs_mount                *mp,
> > +     const struct xfs_rmap_irec      *rec,
> > +     const struct failure_info       *notify)
> > +{
> > +     uint64_t pos = rec->rm_offset;
>
> Nit: indenting ^^^^^ here.
>
> > +
> > +     if (notify->startblock > rec->rm_startblock)
> > +             pos += XFS_FSB_TO_B(mp,
> > +                             notify->startblock - rec->rm_startblock);
> > +     return pos >> PAGE_SHIFT;
> > +}
> > +
> > +static unsigned long
> > +xfs_failure_pgcnt(
> > +     struct xfs_mount                *mp,
> > +     const struct xfs_rmap_irec      *rec,
> > +     const struct failure_info       *notify)
> > +{
> > +     xfs_agblock_t start_rec = rec->rm_startblock;
> > +     xfs_agblock_t end_rec = rec->rm_startblock + rec->rm_blockcount;
> > +     xfs_agblock_t start_notify = notify->startblock;
> > +     xfs_agblock_t end_notify = notify->startblock + notify->blockcount;
> > +     xfs_agblock_t start_cross = max(start_rec, start_notify);
> > +     xfs_agblock_t end_cross = min(end_rec, end_notify);
>
> Indenting and rather more local variables than we need?
>
> static unsigned long
> xfs_failure_pgcnt(
>         struct xfs_mount                *mp,
>         const struct xfs_rmap_irec      *rec,
>         const struct failure_info       *notify)
> {
>         xfs_agblock_t                   end_rec;
>         xfs_agblock_t                   end_notify;
>         xfs_agblock_t                   start_cross;
>         xfs_agblock_t                   end_cross;
>
>         start_cross = max(rec->rm_startblock, notify->startblock);
>
>         end_rec = rec->rm_startblock + rec->rm_blockcount;
>         end_notify = notify->startblock + notify->blockcount;
>         end_cross = min(end_rec, end_notify);
>
>         return XFS_FSB_TO_B(mp, end_cross - start_cross) >> PAGE_SHIFT;
> }
>
> > +
> > +     return XFS_FSB_TO_B(mp, end_cross - start_cross) >> PAGE_SHIFT;
> > +}
> > +
> > +static int
> > +xfs_dax_failure_fn(
> > +     struct xfs_btree_cur            *cur,
> > +     const struct xfs_rmap_irec      *rec,
> > +     void                            *data)
> > +{
> > +     struct xfs_mount                *mp = cur->bc_mp;
> > +     struct xfs_inode                *ip;
> > +     struct address_space            *mapping;
> > +     struct failure_info             *notify = data;
> > +     int                             error = 0;
> > +
> > +     if (XFS_RMAP_NON_INODE_OWNER(rec->rm_owner) ||
> > +         (rec->rm_flags & (XFS_RMAP_ATTR_FORK | XFS_RMAP_BMBT_BLOCK))) {
> > +             /* TODO check and try to fix metadata */
> > +             xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_ONDISK);
> > +             return -EFSCORRUPTED;
> > +     }
> > +
> > +     /* Get files that incore, filter out others that are not in use. */
> > +     error = xfs_iget(mp, cur->bc_tp, rec->rm_owner, XFS_IGET_INCORE,
> > +                      0, &ip);
> > +     /* Continue the rmap query if the inode isn't incore */
> > +     if (error == -ENODATA)
> > +             return 0;
> > +     if (error)
> > +             return error;
> > +
> > +     mapping = VFS_I(ip)->i_mapping;
> > +     if (IS_ENABLED(CONFIG_MEMORY_FAILURE)) {
>
> Is there a situation where we can receive media failure notices from DAX
> but CONFIG_MEMORY_FAILURE is not enabled?  (I think the answer is yes?)

Good catch, yes, I was planning to reuse this notification
infrastructure for the "whoops you ripped out your CXL card that was
being used with FSDAX" case. Although, if someone builds the kernel
with CONFIG_MEMORY_FAILURE=n then I think a lack of notification for
that case is to be expected? Perhaps CONFIG_FSDAX should just depend
on CONFIG_MEMORY_FAILURE when that "hot remove" failure case is added.
For now, CONFIG_MEMORY_FAILURE is the only source of errors.

>
> > +             pgoff_t off = xfs_failure_pgoff(mp, rec, notify);
> > +             unsigned long cnt = xfs_failure_pgcnt(mp, rec, notify);
> > +
> > +             error = mf_dax_kill_procs(mapping, off, cnt, notify->mf_flags);
> > +     }
>
> If so, then we ought to do /something/ besides silently dropping the
> error, right?  Even if that something is rudely shutting down the fs,
> like we do for attr/bmbt mappings above?
>
> What I'm getting at is that I think this function should be:
>
> #if IS_ENABLED(CONFIG_MEMORY_FAILURE)
> static int
> xfs_dax_failure_fn(
>         struct xfs_btree_cur            *cur,
>         const struct xfs_rmap_irec      *rec,
>         void                            *data)
> {
>         /* shut down if attr/bmbt record like above */
>
>         error = xfs_iget(...);
>         if (error == -ENODATA)
>                 return 0;
>         if (error)
>                 return error;
>
>         off = xfs_failure_pgoff(mp, rec, notify);
>         cnt = xfs_failure_pgcnt(mp, rec, notify);
>
>         error = mf_dax_kill_procs(mapping, off, cnt, notify->mf_flags);
>         xfs_irele(ip);
>         return error;
> }
> #else
> static int
> xfs_dax_failure_fn(
>         struct xfs_btree_cur            *cur,
>         const struct xfs_rmap_irec      *rec,
>         void                            *data)
> {
>         /* No other option besides shutting down the fs. */
>         xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_ONDISK);
>         return -EFSCORRUPTED;
> }
> #endif /* CONFIG_MEMORY_FAILURE */

Oh, yeah that makes sense to me.

  reply	other threads:[~2022-01-05 21:17 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-26 14:34 [PATCH v9 00/10] fsdax: introduce fs query to support reflink Shiyang Ruan
2021-12-26 14:34 ` [PATCH v9 01/10] dax: Use percpu rwsem for dax_{read,write}_lock() Shiyang Ruan
2022-01-04 22:44   ` Dan Williams
2022-01-05 17:45     ` Darrick J. Wong
2022-01-06 11:06     ` Shiyang Ruan
2021-12-26 14:34 ` [PATCH v9 02/10] dax: Introduce holder for dax_device Shiyang Ruan
2022-01-05 18:12   ` Darrick J. Wong
2022-01-05 18:23     ` Dan Williams
2022-01-05 18:56       ` Darrick J. Wong
2022-01-05 19:20         ` Dan Williams
2022-01-05 22:47           ` Darrick J. Wong
2022-01-05 23:01             ` Dan Williams
2022-01-05 23:54               ` Darrick J. Wong
2022-01-06  0:12                 ` Dan Williams
2022-01-20  8:46                   ` Christoph Hellwig
2022-01-21  1:26                     ` Shiyang Ruan
2022-01-21  2:22                       ` Darrick J. Wong
2022-01-21  7:17                         ` Christoph Hellwig
2022-02-15 21:51                         ` Dan Williams
2021-12-26 14:34 ` [PATCH v9 03/10] mm: factor helpers for memory_failure_dev_pagemap Shiyang Ruan
2021-12-26 14:34 ` [PATCH v9 04/10] pagemap,pmem: Introduce ->memory_failure() Shiyang Ruan
2022-01-05 19:06   ` Darrick J. Wong
2021-12-26 14:34 ` [PATCH v9 05/10] fsdax: fix function description Shiyang Ruan
2022-01-05 17:50   ` Darrick J. Wong
2022-01-20  8:47   ` Christoph Hellwig
2021-12-26 14:34 ` [PATCH v9 06/10] fsdax: Introduce dax_lock_mapping_entry() Shiyang Ruan
2022-01-04 22:55   ` Dan Williams
2021-12-26 14:34 ` [PATCH v9 07/10] mm: move pgoff_address() to vma_pgoff_address() Shiyang Ruan
2022-01-20  8:47   ` Christoph Hellwig
2021-12-26 14:34 ` [PATCH v9 08/10] mm: Introduce mf_dax_kill_procs() for fsdax case Shiyang Ruan
2022-01-20  8:55   ` Christoph Hellwig
2021-12-26 14:34 ` [PATCH v9 09/10] xfs: Implement ->notify_failure() for XFS Shiyang Ruan
2022-01-05 18:53   ` Darrick J. Wong
2022-01-05 21:17     ` Dan Williams [this message]
2021-12-26 14:34 ` [PATCH v9 10/10] fsdax: set a CoW flag when associate reflink mappings Shiyang Ruan
2022-01-20  8:59   ` Christoph Hellwig
2022-01-21  2:33     ` Shiyang Ruan
2022-01-21  7:16       ` Christoph Hellwig
2022-01-21  8:34         ` Shiyang Ruan

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='CAPcyv4jYOvK57LqGzvZwyHo=4sEKmdAV1jgCzDw5eeCySPGS6w@mail.gmail.com' \
    --to=dan.j.williams@intel.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=jane.chu@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=ruansy.fnst@fujitsu.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 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.