Linux-XFS Archive on lore.kernel.org
 help / color / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 09/10] xfs: validate feature support when recovering rmap/refcount/bmap intents
Date: Sun, 6 Dec 2020 15:08:42 -0800
Message-ID: <20201206230842.GI629293@magnolia> (raw)
In-Reply-To: <20201204140036.GK1404170@bfoster>

On Fri, Dec 04, 2020 at 09:00:36AM -0500, Brian Foster wrote:
> On Thu, Dec 03, 2020 at 05:12:30PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > The bmap, rmap, and refcount log intent items were added to support the
> > rmap and reflink features.  Because these features come with changes to
> > the ondisk format, the log items aren't tied to a log incompat flag.
> > 
> > However, the log recovery routines don't actually check for those
> > feature flags.  The kernel has no business replayng an intent item for a
> > feature that isn't enabled, so check that as part of recovered log item
> > validation.  (Note that kernels pre-dating rmap and reflink will fail
> > the mount on the unknown log item type code.)
> > 
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > ---
> >  fs/xfs/xfs_bmap_item.c     |    4 ++++
> >  fs/xfs/xfs_refcount_item.c |    3 +++
> >  fs/xfs/xfs_rmap_item.c     |    3 +++
> >  3 files changed, 10 insertions(+)
> > 
> > 
> > diff --git a/fs/xfs/xfs_bmap_item.c b/fs/xfs/xfs_bmap_item.c
> > index 78346d47564b..4ea9132716c6 100644
> > --- a/fs/xfs/xfs_bmap_item.c
> > +++ b/fs/xfs/xfs_bmap_item.c
> > @@ -425,6 +425,10 @@ xfs_bui_validate(
> >  {
> >  	struct xfs_map_extent		*bmap;
> >  
> > +	if (!xfs_sb_version_hasrmapbt(&mp->m_sb) &&
> > +	    !xfs_sb_version_hasreflink(&mp->m_sb))
> > +		return false;
> > +
> 
> Took me a minute to realize we use the map/unmap for extent swap if rmap
> is enabled. That does make me wonder a bit.. had we made this kind of
> recovery feature validation change before that came around (such that we
> probably would have only checked _hasreflink() here), would we have
> created an unnecessary backwards incompatibility?

Yes.

I confess to cheating a little here -- technically the bmap intents were
introduced with reflink in 4.9, whereas rmap was introduced in 4.8.  The
proper solution is probably to introduce a new log incompat bit for bmap
intents when reflink isn't enabled, but TBH there were enough other rmap
bugs in 4.8 (not to mention the EXPERIMENTAL warning) that nobody should
be running that old of a kernel on a production system.

(Also we don't enable rmap by default yet whereas reflink has been
enabled by default since 4.18, so the number of people affected probably
isn't very high...)

Secondary question: should we patch 4.9 and 4.14 to disable rmap and
reflink support, since they both still have EXPERIMENTAL warnings?

--D

> Brian
> 
> >  	/* Only one mapping operation per BUI... */
> >  	if (buip->bui_format.bui_nextents != XFS_BUI_MAX_FAST_EXTENTS)
> >  		return false;
> > diff --git a/fs/xfs/xfs_refcount_item.c b/fs/xfs/xfs_refcount_item.c
> > index 8ad6c81f6d8f..2b28f5643c0b 100644
> > --- a/fs/xfs/xfs_refcount_item.c
> > +++ b/fs/xfs/xfs_refcount_item.c
> > @@ -423,6 +423,9 @@ xfs_cui_validate_phys(
> >  	struct xfs_mount		*mp,
> >  	struct xfs_phys_extent		*refc)
> >  {
> > +	if (!xfs_sb_version_hasreflink(&mp->m_sb))
> > +		return false;
> > +
> >  	if (refc->pe_flags & ~XFS_REFCOUNT_EXTENT_FLAGS)
> >  		return false;
> >  
> > diff --git a/fs/xfs/xfs_rmap_item.c b/fs/xfs/xfs_rmap_item.c
> > index f296ec349936..2628bc0080fe 100644
> > --- a/fs/xfs/xfs_rmap_item.c
> > +++ b/fs/xfs/xfs_rmap_item.c
> > @@ -466,6 +466,9 @@ xfs_rui_validate_map(
> >  	struct xfs_mount		*mp,
> >  	struct xfs_map_extent		*rmap)
> >  {
> > +	if (!xfs_sb_version_hasrmapbt(&mp->m_sb))
> > +		return false;
> > +
> >  	if (rmap->me_flags & ~XFS_RMAP_EXTENT_FLAGS)
> >  		return false;
> >  
> > 
> 

  reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04  1:11 [PATCH v2 00/10] xfs: strengthen log intent validation Darrick J. Wong
2020-12-04  1:11 ` [PATCH 01/10] xfs: hoist recovered bmap intent checks out of xfs_bui_item_recover Darrick J. Wong
2020-12-04 13:55   ` Brian Foster
2020-12-04  1:11 ` [PATCH 02/10] xfs: improve the code that checks recovered bmap intent items Darrick J. Wong
2020-12-04 13:56   ` Brian Foster
2020-12-04 19:54     ` Darrick J. Wong
2020-12-04  1:11 ` [PATCH 03/10] xfs: hoist recovered rmap intent checks out of xfs_rui_item_recover Darrick J. Wong
2020-12-04 13:59   ` Brian Foster
2020-12-04  1:12 ` [PATCH 04/10] xfs: improve the code that checks recovered rmap intent items Darrick J. Wong
2020-12-04 13:59   ` Brian Foster
2020-12-04  1:12 ` [PATCH 05/10] xfs: hoist recovered refcount intent checks out of xfs_cui_item_recover Darrick J. Wong
2020-12-04 14:00   ` Brian Foster
2020-12-04  1:12 ` [PATCH 06/10] xfs: improve the code that checks recovered refcount intent items Darrick J. Wong
2020-12-04 14:00   ` Brian Foster
2020-12-04  1:12 ` [PATCH 07/10] xfs: hoist recovered extent-free intent checks out of xfs_efi_item_recover Darrick J. Wong
2020-12-04 14:00   ` Brian Foster
2020-12-04  1:12 ` [PATCH 08/10] xfs: improve the code that checks recovered extent-free intent items Darrick J. Wong
2020-12-04 14:00   ` Brian Foster
2020-12-04  1:12 ` [PATCH 09/10] xfs: validate feature support when recovering rmap/refcount/bmap intents Darrick J. Wong
2020-12-04 14:00   ` Brian Foster
2020-12-06 23:08     ` Darrick J. Wong [this message]
2020-12-07 14:02       ` Brian Foster
2020-12-07 16:50         ` Darrick J. Wong
2020-12-04  1:12 ` [PATCH 10/10] xfs: trace log intent item recovery failures Darrick J. Wong
2020-12-04 14:00   ` Brian Foster
2020-12-04 19:57     ` Darrick J. Wong
  -- strict thread matches above, loose matches on Subject: below --
2020-12-06 23:09 [PATCH v3 00/10] xfs: strengthen log intent validation Darrick J. Wong
2020-12-06 23:10 ` [PATCH 09/10] xfs: validate feature support when recovering rmap/refcount/bmap intents Darrick J. Wong
2020-12-01  3:37 [PATCH 00/10] xfs: strengthen log intent validation Darrick J. Wong
2020-12-01  3:38 ` [PATCH 09/10] xfs: validate feature support when recovering rmap/refcount/bmap intents Darrick J. Wong
2020-12-01 10:07   ` 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=20201206230842.GI629293@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=bfoster@redhat.com \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.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

Linux-XFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-xfs/0 linux-xfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-xfs linux-xfs/ https://lore.kernel.org/linux-xfs \
		linux-xfs@vger.kernel.org
	public-inbox-index linux-xfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-xfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git