Re: [PATCH] stable: restart busy extent search after node removal

[Dave Chinner <david@fromorbit.com>]

On Tue, Jul 12, 2011 at 05:03:38PM -0500, Eric Sandeen wrote:
> Sending this for review prior to stable submission...
> 
> A user on #xfs reported that a log replay was oopsing in
> __rb_rotate_left() with a null pointer deref.
> 
> I traced this down to the fact that in xfs_alloc_busy_insert(),
> we erased a node with rb_erase() when the new node overlapped,
> but left it specified as the parent node for the new insertion.
> 
> So when we try to insert a new node with an erased node as
> its parent, obviously things go very wrong.
> 
> Upstream,
> 97d3ac75e5e0ebf7ca38ae74cebd201c09b97ab2 xfs: exact busy extent tracking
> actually fixed this, but as part of a much larger change.  Here's
> the relevant bit:
> 
>                 * We also need to restart the busy extent search from the
>                 * tree root, because erasing the node can rearrange the
>                 * tree topology.
>                 */
>                rb_erase(&busyp->rb_node, &pag->pagb_tree);
>                busyp->length = 0;
>                return false;
> 
> We can do essentially the same thing to older codebases by restarting
> the search after the erase.
> 
> This should apply to .35 through .39, and was tested on .39
> with the oopsing replay reproducer.
> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
> 
> Index: linux-2.6/fs/xfs/xfs_alloc.c
> ===================================================================
> --- linux-2.6.orig/fs/xfs/xfs_alloc.c
> +++ linux-2.6/fs/xfs/xfs_alloc.c
> @@ -2664,6 +2664,12 @@ restart:
>  					new->bno + new->length) -
>  				min(busyp->bno, new->bno);
>  		new->bno = min(busyp->bno, new->bno);
> +		/*
> +		 * Start the search over from the tree root, because
> +		 * erasing the node can rearrange the tree topology.
> +		 */
> +		spin_unlock(&pag->pagb_lock);
> +		goto restart;
>  	} else
>  		busyp = NULL;

Looks good.

I'm guessing that the only case I was able to hit during testing of
this code originally was the "overlap with exact start block match",
otherwise I would have seen this. I'm not sure that there really is
much we can do to improve the test coverage of this code, though.
Hell, just measuring our test coverage so we know what we aren't
testing would probably be a good start. :/

Reviewed-by: Dave Chinner <dchinner@redhat.com>

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs