From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/6] xfs: verify extent size hint is valid in inode verifier
Date: Fri, 8 Jun 2018 11:10:39 +1000 [thread overview]
Message-ID: <20180608011039.GZ10363@dastard> (raw)
In-Reply-To: <20180607161631.GM25007@magnolia>
On Thu, Jun 07, 2018 at 09:16:31AM -0700, Darrick J. Wong wrote:
> On Tue, Jun 05, 2018 at 10:10:15AM -0700, Darrick J. Wong wrote:
> > On Tue, Jun 05, 2018 at 04:24:19PM +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>
> >
> > Looks ok modulo my comments in the next patch,
> > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
>
> FWIW when I applied this to xfsprogs I saw an xfs/033 regression:
>
> Phase 6 - check inode connectivity...
> reinitializing root directory
> Metadata corruption detected at 0x5555555c60e0, inode 0x80 dinode
>
> fatal error -- could not iget root inode -- error - 117
> [Inferior 1 (process 1178) exited with code 01]
> (gdb) l *(0x5555555c60e0)
> 0x5555555c60e0 is in libxfs_inode_validate_extsize (xfs_inode_buf.c:729).
>
> We fail the inode verifier while trying to _iget the root inode so that
> we can reinitialize it; I suspect phase 3 is going to need to check the
> extent size hints and clear them.
I'm actually quite happy to see that the continual process of
hardening the kernel verifiers has got to the point where we are
starting to expose deficiencies in xfs_repair.
Can I wait for the xfsprogs libxfs-4.18-sync branch to pick up these
verifier changes before looking at what repair needs to do to avoid
it? I don't want to do a forced context switch to
debugging/enhancing userspace code right at this moment....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-06-08 1:10 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-05 6:24 [PATCH 0/6 V2] xfs: more verifications! Dave Chinner
2018-06-05 6:24 ` [PATCH 1/6] xfs: catch bad stripe alignment configurations Dave Chinner
2018-06-05 9:27 ` Carlos Maiolino
2018-06-05 6:24 ` [PATCH 2/6] xfs: verify extent size hint is valid in inode verifier Dave Chinner
2018-06-05 9:53 ` Carlos Maiolino
2018-06-05 22:56 ` Dave Chinner
2018-06-05 17:10 ` Darrick J. Wong
2018-06-07 16:16 ` Darrick J. Wong
2018-06-08 1:10 ` Dave Chinner [this message]
2018-06-08 1:23 ` Darrick J. Wong
2018-06-08 2:23 ` Eric Sandeen
2018-07-24 6:39 ` Eric Sandeen
2018-07-24 16:43 ` Darrick J. Wong
2018-08-20 15:06 ` Brian Foster
2018-08-20 15:27 ` Eric Sandeen
2018-08-20 15:36 ` Darrick J. Wong
2018-08-20 15:59 ` Brian Foster
2018-08-20 22:15 ` Dave Chinner
2018-08-21 10:56 ` Brian Foster
2018-08-22 0:41 ` Dave Chinner
2018-06-05 6:24 ` [PATCH 3/6] xfs: verify COW " Dave Chinner
2018-06-05 10:00 ` Carlos Maiolino
2018-06-05 17:09 ` Darrick J. Wong
2018-06-05 6:24 ` [PATCH 4/6] xfs: validate btree records on retreival Dave Chinner
2018-06-05 6:40 ` [PATCH 4/6 v2] " Dave Chinner
2018-06-05 10:42 ` Carlos Maiolino
2018-06-05 23:00 ` Dave Chinner
2018-06-05 17:47 ` Darrick J. Wong
2018-06-05 23:02 ` Dave Chinner
2018-06-06 1:21 ` [PATCH 4/6 v3] " Dave Chinner
2018-06-05 6:24 ` [PATCH 5/6] xfs: verify root inode more thoroughly Dave Chinner
2018-06-05 10:50 ` Carlos Maiolino
2018-06-05 17:10 ` Darrick J. Wong
2018-06-05 6:24 ` [PATCH 6/6] xfs: push corruption -> ESTALE conversion to xfs_nfs_get_inode() Dave Chinner
2018-06-05 11:12 ` Carlos Maiolino
2018-06-05 17:11 ` 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=20180608011039.GZ10363@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).