All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/3] xfs: verify extent size hint is valid in inode verifier
Date: Tue, 5 Jun 2018 14:47:29 +1000	[thread overview]
Message-ID: <20180605044729.GD10363@dastard> (raw)
In-Reply-To: <20180605042836.GF9437@magnolia>

On Mon, Jun 04, 2018 at 09:28:36PM -0700, Darrick J. Wong wrote:
> On Tue, Jun 05, 2018 at 02:24:53PM +1000, Dave Chinner wrote:
> > On Mon, Jun 04, 2018 at 09:08:17PM -0700, Darrick J. Wong wrote:
> > > On Tue, Jun 05, 2018 at 12:43:12PM +1000, Dave Chinner wrote:
> > > > From: Dave Chinner <dchinner@redhat.com>
> > > > 
> > > > There are rules for vald extent size hints. We enforce them when
> > > > applications set them, but fuzzers violate those rules and that
> > > > screws us over.
> > > > 
> > > > This results in alignment assertion failures when setting up
> > > > allocations such as this in direct IO:
> > > > 
> > > > XFS: Assertion failed: ap->length, file: fs/xfs/libxfs/xfs_bmap.c, line: 3432
> > > > ....
> > > > Call Trace:
> > > >  xfs_bmap_btalloc+0x415/0x910
> > > >  xfs_bmapi_write+0x71c/0x12e0
> > > >  xfs_iomap_write_direct+0x2a9/0x420
> > > >  xfs_file_iomap_begin+0x4dc/0xa70
> > > >  iomap_apply+0x43/0x100
> > > >  iomap_file_buffered_write+0x62/0x90
> > > >  xfs_file_buffered_aio_write+0xba/0x300
> > > >  __vfs_write+0xd5/0x150
> > > >  vfs_write+0xb6/0x180
> > > >  ksys_write+0x45/0xa0
> > > >  do_syscall_64+0x5a/0x180
> > > >  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > > 
> > > > And from xfs_db:
> > > > 
> > > > core.extsize = 10380288
> > > > 
> > > > Which is not an integer multiple of the block size, and so violates
> > > > Rule #7 for setting extent size hints. Validate extent size hint
> > > > rules in the inode verifier to catch this.
> > > > 
> > > > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > > > ---
> > > >  fs/xfs/libxfs/xfs_inode_buf.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/fs/xfs/libxfs/xfs_inode_buf.c b/fs/xfs/libxfs/xfs_inode_buf.c
> > > > index f5fff1ccb61d..be197c91307b 100644
> > > > --- a/fs/xfs/libxfs/xfs_inode_buf.c
> > > > +++ b/fs/xfs/libxfs/xfs_inode_buf.c
> > > > @@ -385,6 +385,7 @@ xfs_dinode_verify(
> > > >  	xfs_ino_t		ino,
> > > >  	struct xfs_dinode	*dip)
> > > >  {
> > > > +	xfs_failaddr_t		fa;
> > > >  	uint16_t		mode;
> > > >  	uint16_t		flags;
> > > >  	uint64_t		flags2;
> > > > @@ -501,6 +502,12 @@ xfs_dinode_verify(
> > > >  			return __this_address;
> > > >  	}
> > > >  
> > > > +	/* extent size hint validation */
> > > > +	fa = xfs_inode_validate_extsize(mp, be32_to_cpu(dip->di_extsize),
> > > > +					mode, be32_to_cpu(dip->di_flags));
> > > 
> > > What if the cowextsize is garbage?  Do we handle that better, or do we
> > > blow up there too?
> > 
> > I haven't checked (it was a v4 image that I was looking at) - are
> > the rules the same?
> 
> Similar, but not entirely the same.  See xfs_inode_validate_cowextsize. :)

OK, I'll cook up a similar patch then.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2018-06-05  4:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-05  2:43 [PATCH 0/3] xfs: more verifications! Dave Chinner
2018-06-05  2:43 ` [PATCH 1/3] xfs: catch bad stripe alignment configurations Dave Chinner
2018-06-05  3:44   ` Darrick J. Wong
2018-06-05  2:43 ` [PATCH 2/3] xfs: verify extent size hint is valid in inode verifier Dave Chinner
2018-06-05  4:08   ` Darrick J. Wong
2018-06-05  4:24     ` Dave Chinner
2018-06-05  4:28       ` Darrick J. Wong
2018-06-05  4:47         ` Dave Chinner [this message]
2018-06-05  2:43 ` [PATCH 3/3] xfs: validate btree records on retreival Dave Chinner
2018-06-05  4:02   ` Darrick J. Wong
2018-06-05  4:39     ` Dave Chinner
2018-06-05  5:08       ` Dave Chinner
2018-06-05  2:57 ` [PATCH 4/3] xfs: verify root inode more thoroughly Dave Chinner
2018-06-05  4:06   ` Darrick J. Wong
2018-06-05  5:30     ` Dave Chinner
2018-06-05  3:38 ` [PATCH 0/3] xfs: more verifications! Darrick J. Wong
2018-06-05  4:44   ` 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=20180605044729.GD10363@dastard \
    --to=david@fromorbit.com \
    --cc=darrick.wong@oracle.com \
    --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.