Re: [PATCH] xfs: don't crash on unexpected holes in dir/attr btrees

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Tue, Jun 20, 2017 at 02:06:07AM -0700, Christoph Hellwig wrote:
> On Fri, Jun 16, 2017 at 01:12:41PM -0500, Eric Sandeen wrote:
> > On 6/16/17 12:53 PM, Darrick J. Wong wrote:
> > > Hi all,
> > > 
> > > So I /think/ the xfs_attr_inactive crashes that both of you have been
> > > seeing are a result of XFS assuming that there aren't ever any mapping
> > > holes in the extended attribute fork and crashing when it tries to
> > > grab a buffer for the hole and fails to notice that holes don't have
> > > buffers.  This lightly tested patch gets rid of /that/ problem.
> > > 
> > > So, if you're willing, can you try this out and see if the crashes go
> > > away?  Granted, this might only enable us to lurch on whatever's next...
> > 
> > If it's unexpected, does that mean something else is wrong?  If so,
> > should there be a warning or a corrupted state, or anything like that?
> 
> xfs_attr_rmtval_remove certainly removes blocks from the attr mapping,
> but those should be expected..

Yes, I think pretty much any attribute removal can result in blocks
being removed from the attribute mapping, but here we have the case that
the da btree points to some offset... but the offset isn't mapped and so
the attr_inactive call blows up.

That said, this patch also fixes the remaining cases where someone
deliberately feeds us a corrupt filesystem and we blow up trying to
xfs_trans_buf_set_type on a null buffer, so can I please get a review of
this patch so I can push it upstream? :)

--D

> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html