Re: [patch] btrfs: fix inode rbtree corruption

Yan, Zheng
2009-08-21T00:55:20Z

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 thi=
s particular
>> >> > > > code does not.
>> >> > > >
>> >> > > > It is pretty easy obviously to put in duplicates because th=
e rbtree
>> >> > > > code doesn't know about keys, but if we do this then it loo=
ks like
>> >> > > > it might cause the search code to miss some valid inodes an=
d instead
>> >> > > > return freeing inodes -- so you'd also have to look at that=
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 co=
de (hence
>> >> > > my comment about potential lookup bug, if you allow aliases y=
ou have to
>> >> > > be careful).
>> >> >
>> >> > Ah ok. Well yeah in this case btrfs is definitely wrong in the =
way it
>> >> > tried to insert aliases.
>> >>
>> >> I looked at the actual problem now and I agree, it cannot work th=
at way.
>> >> I don't know if Linus is planning another -rc, we should probably=
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?

No. Jens, please submit it. Thanks

Yan, Zheng
--
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