[Top] [All Lists]

Re: [PATCH] xfs: fix attr tree double split corruption

To: Peter Huewe <peterhuewe@xxxxxx>
Subject: Re: [PATCH] xfs: fix attr tree double split corruption
From: Dave Chinner <dchinner@xxxxxxxxxx>
Date: Fri, 23 Nov 2012 11:49:37 +1100
Cc: stable@xxxxxxxxxxxxxxx, Ben Myers <bpm@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <1353625175-29479-1-git-send-email-peterhuewe@xxxxxx>
References: <1353625175-29479-1-git-send-email-peterhuewe@xxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
[added xfs@xxxxxxxxxxx]

On Thu, Nov 22, 2012 at 11:59:35PM +0100, Peter Huewe wrote:
> In certain circumstances, a double split of an attribute tree is
> needed to insert or replace an attribute. In rare situations, this
> can go wrong, leaving the attribute tree corrupted. In this case,
> the attr being replaced is the last attr in a leaf node, and the
> replacement is larger so doesn't fit in the same leaf node.
> When we have the initial condition of a node format attribute
> btree with two leaves at index 1 and 2. Call them L1 and L2.  The
> leaf L1 is completely full, there is not a single byte of free space
> in it. L2 is mostly empty.  The attribute being replaced - call it X
> - is the last attribute in L1.

Hi Peter,

While I appreciate what you are doing here, can you please send
stable backport patches to the xfs@xxxxxxxxxxx list for review
before sending them to stable@xxxxxxxxxxxxxxx? There may already be
someone doing this work, and we want to make sure that backports are
correct, tested and worth the risk of fixing before asking the
(already overworked) stable kernel maintainers to include it.

As such, how did you test that the fix works on the stable kernels
you are targetting? AFAIK, I'm the only person who has the
filesystem images that reproducably triggered this corruption

> Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
> Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
> Signed-off-by: Ben Myers <bpm@xxxxxxx>
> Cc: <stable@xxxxxxxxxxxxxxx> # 3.6.x
> Cc: <stable@xxxxxxxxxxxxxxx> # 3.4.x
> Cc: <stable@xxxxxxxxxxxxxxx> # 3.2.x

If we are pushing this fix back to stable kernels, then it
should go back to 3.0.x as well.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>