Re: [patch] btrfs: fix inode rbtree corruption

[Jens Axboe <jens.axboe@oracle.com>]

On Fri, Aug 21 2009, Yan, Zheng  wrote:
> 2009/8/21 Jens Axboe <jens.axboe@oracle.com>:
> > On Thu, Aug 20 2009, Yan, Zheng =A0wrote:
> >> 2009/8/20 Nick Piggin <npiggin@suse.de>:
> >> > On Wed, Aug 19, 2009 at 10:59:07AM +0200, Jens Axboe wrote:
> >> >> On Wed, Aug 19 2009, Nick Piggin wrote:
> >> >> > On Wed, Aug 19, 2009 at 10:46:59AM +0200, Jens Axboe wrote:
> >> >> > > On Wed, Aug 19 2009, Nick Piggin wrote:
> >> >> > > > See my other reply. It *can* work with key aliases, but t=
his particular
> >> >> > > > code does not.
> >> >> > > >
> >> >> > > > It is pretty easy obviously to put in duplicates because =
the rbtree
> >> >> > > > code doesn't know about keys, but if we do this then it l=
ooks like
> >> >> > > > it might cause the search code to miss some valid inodes =
and instead
> >> >> > > > return freeing inodes -- so you'd also have to look at th=
at and update
> >> >> > > > it which is why I didn't go down this route..
> >> >> > >
> >> >> > > Mine was just a generic statement, I didn't read the btrfs =
code (hence
> >> >> > > my comment about potential lookup bug, if you allow aliases=
 you have to
> >> >> > > be careful).
> >> >> >
> >> >> > Ah ok. Well yeah in this case btrfs is definitely wrong in th=
e way it
> >> >> > tried to insert aliases.
> >> >>
> >> >> I looked at the actual problem now and I agree, it cannot work =
that way.
> >> >> I don't know if Linus is planning another -rc, we should probab=
ly get
> >> >> this upstream sooner rather than later. Chris is away this week=
, so if
> >> >> we can get Yan to agree on this patch as well, I'll submit it.
> >> > I think the first patch I submitted was agreed?
> >> >
> >>
> >> Of course, thank you.
> > Yan, are you sending this upstream?
>=20
> No.  Jens, please submit it. Thanks

Will do. Can I add your acked-by?

--=20
Jens Axboe

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