All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/3] xfs: simplify validation of the unwritten extent bit
Date: Thu, 20 Apr 2017 09:56:20 -0700	[thread overview]
Message-ID: <20170420165620.GF5205@birch.djwong.org> (raw)
In-Reply-To: <20170420143857.GB22644@lst.de>

On Thu, Apr 20, 2017 at 04:38:57PM +0200, Christoph Hellwig wrote:
> [can you trim the quote?  Makes reading it and properly quoting it
>  so much easier..]
> 
> > > +static inline bool xfs_bmbt_validate_extent(struct xfs_mount *mp, int whichfork,
> > > +		struct xfs_bmbt_rec_host *ep)
> > 
> > Would be nice to have this function formatted the same way as most of
> > the rest of the xfs functions, even if it is static inline...
> 
> It's actually the usual style for our inlines.  But if you prefer it
> differently I can do that.

Nah, don't worry about it.

Though I do wonder why static inlines get different treatment; it's
rather nice to be able to search for ^xfs_function and find its
definition.

> > Wouldn't this be better off in xfs_iflush_int (like the inline dir
> > verifier) since we could prevent bad metadata from hitting the disk?
> > Rather than this, which doesn't do anything on non-debug kernels.
> 
> xfs_iflush_int actually calls xfs_iflush_fork which calls
> xfs_iextents_copy, so it's in the right spot already.  Converting it
> from an assert to an error would have to go through these layers
> that don't currently expect errors.  Note that we also call
> xfs_iextents_copy from xfs_inode_item_format_data_fork /
> xfs_inode_item_format_attr_fork, which are called earlier than
> xfs_iflush_int, where error propagation is even worse.

Fair enough.  The rest looks ok, so I'll go run it through testing.

--D

      reply	other threads:[~2017-04-20 16:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-19 19:29 misc cleanups Christoph Hellwig
2017-04-19 19:29 ` [PATCH 1/3] xfs: remove the unused XFS_MAXLINK_1 define Christoph Hellwig
2017-04-19 19:57   ` Darrick J. Wong
2017-04-19 19:58   ` Eric Sandeen
2017-04-19 19:29 ` [PATCH 2/3] xfs: remove unused values from xfs_exntst_t Christoph Hellwig
2017-04-19 19:59   ` Darrick J. Wong
2017-04-19 19:59   ` Eric Sandeen
2017-04-19 19:29 ` [PATCH 3/3] xfs: simplify validation of the unwritten extent bit Christoph Hellwig
2017-04-19 20:17   ` Darrick J. Wong
2017-04-20 14:38     ` Christoph Hellwig
2017-04-20 16:56       ` Darrick J. Wong [this message]

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=20170420165620.GF5205@birch.djwong.org \
    --to=darrick.wong@oracle.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
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.