From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/5] xfs: make superblock version checks reflect reality
Date: Tue, 6 May 2014 01:29:48 -0700 [thread overview]
Message-ID: <20140506082948.GA18865@infradead.org> (raw)
In-Reply-To: <1399348559-19889-2-git-send-email-david@fromorbit.com>
> +/*
> + * The first XFS version we support is a v4 superblock with V2 directories.
> + */
> +static inline bool xfs_sb_good_v4_features(struct xfs_sb *sbp)
> {
> + if (!(sbp->sb_versionnum & XFS_SB_VERSION_DIRV2BIT))
> + return false;
>
> + /* check for unknown features in the fs */
> + if ((sbp->sb_versionnum & ~XFS_SB_VERSION_OKBITS) ||
Given that sb_versionnum is a __uint16_t and XFS_SB_VERSION_OKBITS is
0xffff this will never evaluate to false and a sane compiler should warn
about it. How about remove this check and XFS_SB_VERSION_OKBITS?
The various has_ macros are a bit confusing to me, as some explicitly
check for 5 superblocks, and some assume the caller handles them in
some way, but I think this is something we can leave for later cleanups.
> * For example, for a bit defined as XFS_SB_VERSION2_FUNBIT, has a macro:
> *
> - * SB_VERSION_HASFUNBIT(xfs_sb_t *sbp)
> + * SB_VERSION_HASFUNBIT(struct xfs_sb *sbp)
> * ((xfs_sb_version_hasmorebits(sbp) &&
> * ((sbp)->sb_features2 & XFS_SB_VERSION2_FUNBIT)
> */
This should be updated to the lowe case convention inlines we've used
for a long time. Or just removed as new features should go into v5
superblocks..
Modulo these minor bits:
Reviewed-by: Christoph Hellwig <hch@lst.de>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-05-06 8:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 3:55 [PATCH 0/5] xfs: sanitise supberlock feature bit support Dave Chinner
2014-05-06 3:55 ` [PATCH 1/5] xfs: make superblock version checks reflect reality Dave Chinner
2014-05-06 8:29 ` Christoph Hellwig [this message]
2014-05-06 8:39 ` Dave Chinner
2014-05-06 3:55 ` [PATCH 2/5] xfs: keep sb_bad_features2 the same a sb_features2 Dave Chinner
2014-05-06 8:20 ` Christoph Hellwig
2014-05-06 3:55 ` [PATCH 3/5] xfs: turn NLINK feature on by default Dave Chinner
2014-05-06 8:15 ` Christoph Hellwig
2014-05-06 9:06 ` Dave Chinner
2014-05-06 3:55 ` [PATCH 4/5] xfs: don't need dirv2 checks anymore Dave Chinner
2014-05-06 8:16 ` Christoph Hellwig
2014-05-06 8:45 ` Dave Chinner
2014-05-06 3:55 ` [PATCH 5/5] xfs: remove shared supberlock feature checking Dave Chinner
2014-05-06 7:48 ` Jeff Liu
2014-05-06 8:02 ` Dave Chinner
2014-05-06 8:18 ` Christoph Hellwig
2014-05-06 8:28 ` Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2014-05-16 23:00 [PATCH 0/5 V2] xfs: sanitise superblock feature bit support Dave Chinner
2014-05-16 23:00 ` [PATCH 1/5] xfs: make superblock version checks reflect reality Dave Chinner
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=20140506082948.GA18865@infradead.org \
--to=hch@infradead.org \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox