All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"david@fromorbit.com" <david@fromorbit.com>,
	"hch@infradead.org" <hch@infradead.org>,
	"jane.chu@oracle.com" <jane.chu@oracle.com>
Subject: Re: [PATCH v7] mm, pmem, xfs: Introduce MF_MEM_REMOVE for unbind
Date: Mon, 29 Aug 2022 07:49:55 -0700	[thread overview]
Message-ID: <YwzSE2U8iYLRfyxf@magnolia> (raw)
In-Reply-To: <72fa9657-741a-e099-baf8-4615145d7bd1@fujitsu.com>

On Mon, Aug 29, 2022 at 06:02:11PM +0800, Shiyang Ruan wrote:
> 
> 
> 在 2022/8/27 5:35, Dan Williams 写道:
> > Shiyang Ruan wrote:
> > > This patch is inspired by Dan's "mm, dax, pmem: Introduce
> > > dev_pagemap_failure()"[1].  With the help of dax_holder and
> > > ->notify_failure() mechanism, the pmem driver is able to ask filesystem
> > > (or mapped device) on it to unmap all files in use and notify processes
> > > who are using those files.
> > > 
> > > Call trace:
> > > trigger unbind
> > >    -> unbind_store()
> > >     -> ... (skip)
> > >      -> devres_release_all()
> > >       -> kill_dax()
> > >        -> dax_holder_notify_failure(dax_dev, 0, U64_MAX, MF_MEM_PRE_REMOVE)
> > >         -> xfs_dax_notify_failure()
> > > 
> > > Introduce MF_MEM_PRE_REMOVE to let filesystem know this is a remove
> > > event.  So do not shutdown filesystem directly if something not
> > > supported, or if failure range includes metadata area.  Make sure all
> > > files and processes are handled correctly.
> > > 
> > > ==
> > > Changes since v6:
> > >     1. Rebase on 6.0-rc2 and Darrick's patch[2].
> > > 
> > > Changes since v5:
> > >     1. Renamed MF_MEM_REMOVE to MF_MEM_PRE_REMOVE
> > >     2. hold s_umount before sync_filesystem()
> > >     3. do sync_filesystem() after SB_BORN check
> > >     4. Rebased on next-20220714
> > > 
> > > [1]:
> > > https://lore.kernel.org/linux-mm/161604050314.1463742.14151665140035795571.stgit@dwillia2-desk3.amr.corp.intel.com/
> > > [2]: https://lore.kernel.org/linux-xfs/Yv5wIa2crHioYeRr@magnolia/
> > > 
> > > Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
> > > Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> > > ---
> > >    drivers/dax/super.c         |  3 ++-
> > >    fs/xfs/xfs_notify_failure.c | 15 +++++++++++++++
> > >    include/linux/mm.h          |  1 +
> > >    3 files changed, 18 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> > > index 9b5e2a5eb0ae..cf9a64563fbe 100644
> > > --- a/drivers/dax/super.c
> > > +++ b/drivers/dax/super.c
> > > @@ -323,7 +323,8 @@ void kill_dax(struct dax_device *dax_dev)
> > >    		return;
> > >     	if (dax_dev->holder_data != NULL)
> > > -		dax_holder_notify_failure(dax_dev, 0, U64_MAX, 0);
> > > +		dax_holder_notify_failure(dax_dev, 0, U64_MAX,
> > > +				MF_MEM_PRE_REMOVE);
> > >     	clear_bit(DAXDEV_ALIVE, &dax_dev->flags);
> > >    	synchronize_srcu(&dax_srcu);
> > > diff --git a/fs/xfs/xfs_notify_failure.c b/fs/xfs/xfs_notify_failure.c
> > > index 65d5eb20878e..a9769f17e998 100644
> > > --- a/fs/xfs/xfs_notify_failure.c
> > > +++ b/fs/xfs/xfs_notify_failure.c
> > > @@ -77,6 +77,9 @@ xfs_dax_failure_fn(
> > >     	if (XFS_RMAP_NON_INODE_OWNER(rec->rm_owner) ||
> > >    	    (rec->rm_flags & (XFS_RMAP_ATTR_FORK | XFS_RMAP_BMBT_BLOCK))) {
> > > +		/* Do not shutdown so early when device is to be removed */
> > > +		if (notify->mf_flags & MF_MEM_PRE_REMOVE)
> > > +			return 0;
> > >    		notify->want_shutdown = true;
> > >    		return 0;
> > >    	}
> > > @@ -182,12 +185,22 @@ xfs_dax_notify_failure(
> > >    	struct xfs_mount	*mp = dax_holder(dax_dev);
> > >    	u64			ddev_start;
> > >    	u64			ddev_end;
> > > +	int			error;
> > >     	if (!(mp->m_sb.sb_flags & SB_BORN)) {
> > 
> > How are you testing the SB_BORN interactions? I have a fix for this
> > pending here:
> > 
> > https://lore.kernel.org/nvdimm/166153428094.2758201.7936572520826540019.stgit@dwillia2-xfh.jf.intel.com/
> 
> That was my mistake.  Yes, it should be mp->m_super->s_flags.
> 
> (I remember my testcase did pass in my dev version, but now that seems
> impossible.  I think something was wrong when I did the test.)
> 
> > 
> > >    		xfs_warn(mp, "filesystem is not ready for notify_failure()!");
> > >    		return -EIO;
> > >    	}
> > >    +	if (mf_flags & MF_MEM_PRE_REMOVE) {
> > 
> > It appears this patch is corrupted here. I confirmed that b4 sees the
> > same when trying to apply it.
> 
> Can't this patch be applied?  It is based on 6.0-rc2 + Darrick's patch. It's
> also ok to rebase on 6.0-rc3 + Darrick's patch.
> 
> > 
> > > +		xfs_info(mp, "device is about to be removed!");
> > > +		down_write(&mp->m_super->s_umount);
> > > +		error = sync_filesystem(mp->m_super);
> > 
> > This syncs to make data persistent, but for DAX this also needs to get
> > invalidate all current DAX mappings. I do not see that in these changes.
> 
> I'll add it.

Are you guys going to pick up [1]?

--D

[1] https://lore.kernel.org/linux-xfs/Yv5wIa2crHioYeRr@magnolia/

> 
> --
> Thanks,
> Ruan.
> 
> > 
> > > +		up_write(&mp->m_super->s_umount);
> > > +		if (error)
> > > +			return error;
> > > +	}
> > > +
> > >    	if (mp->m_rtdev_targp && mp->m_rtdev_targp->bt_daxdev == dax_dev) {
> > >    		xfs_warn(mp,
> > >    			 "notify_failure() not supported on realtime device!");
> > > @@ -196,6 +209,8 @@ xfs_dax_notify_failure(
> > >     	if (mp->m_logdev_targp && mp->m_logdev_targp->bt_daxdev == dax_dev &&
> > >    	    mp->m_logdev_targp != mp->m_ddev_targp) {
> > > +		if (mf_flags & MF_MEM_PRE_REMOVE)
> > > +			return 0;
> > >    		xfs_err(mp, "ondisk log corrupt, shutting down fs!");
> > >    		xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_ONDISK);
> > >    		return -EFSCORRUPTED;
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index 982f2607180b..2c7c132e6512 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -3176,6 +3176,7 @@ enum mf_flags {
> > >    	MF_UNPOISON = 1 << 4,
> > >    	MF_SW_SIMULATED = 1 << 5,
> > >    	MF_NO_RETRY = 1 << 6,
> > > +	MF_MEM_PRE_REMOVE = 1 << 7,
> > >    };
> > >    int mf_dax_kill_procs(struct address_space *mapping, pgoff_t index,
> > >    		      unsigned long count, int mf_flags);
> > > -- 
> > > 2.37.2
> > > 
> > > 
> > 
> > 

  reply	other threads:[~2022-08-29 14:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 13:03 [PATCH v7] mm, pmem, xfs: Introduce MF_MEM_REMOVE for unbind Shiyang Ruan
2022-08-26 21:35 ` Dan Williams
2022-08-29 10:02   ` Shiyang Ruan
2022-08-29 14:49     ` Darrick J. Wong [this message]
2022-09-02 10:35 ` [PATCH v8 0/3] " Shiyang Ruan
2022-09-02 10:35   ` [PATCH 1/3] xfs: fix the calculation of length and end Shiyang Ruan
2022-09-14 18:13     ` Darrick J. Wong
2022-09-02 10:36   ` [PATCH 2/3] fs: move drop_pagecache_sb() for others to use Shiyang Ruan
2022-09-14 18:16     ` Darrick J. Wong
2022-09-02 10:36   ` [PATCH 3/3] mm, pmem, xfs: Introduce MF_MEM_REMOVE for unbind Shiyang Ruan
2022-09-14 18:15     ` Darrick J. Wong
2022-09-15  1:49       ` Shiyang Ruan
2022-09-20  2:45     ` Dave Chinner
2022-09-21  0:58       ` Darrick J. Wong
2022-09-07  9:46   ` [PATCH v8 0/3] " Shiyang Ruan
2022-09-14 18:09     ` Darrick J. Wong
2022-09-14 18:15       ` Darrick J. Wong
2022-09-15  2:56         ` Shiyang Ruan
2022-09-16 15:43           ` Darrick J. Wong

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=YwzSE2U8iYLRfyxf@magnolia \
    --to=djwong@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@fromorbit.com \
    --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.