[Ocfs2-tools-devel] [PATCH 2/2] Modify the check in io_cache_disconnect.

[tao.ma]

Joel Becker wrote:
> On Fri, Oct 19, 2007 at 02:57:50PM +0800, Tao Ma wrote:
>   
>> In the io_cache rb-tree, we may want to erase a cached block
>> which is the root of the whole tree. In this scenario, the rb_parent
>> will be NULL. So this io_cache will not be removed by the original
>> io_cache_disconnect and lead to the "assert" problem when we try
>> io_cache_insert by using the same icb.
>>     
>
> 	You've seen this happen in practice, I assume?  The root is
> RB_ROOT, a special value.  It should not be one of the icbs.
> ic->ic_lookup is RB_ROOT, not an icb.
>   
I have seen this happen in practice when I try to use it to speed up the 
extent block iteration. ;)
As for RB_ROOT, if you look at the definition of RB_ROOT and the how we 
use rb_link_node, you will get that we will use ic->ic_lookup->rb_node 
as the real rb-root which can be NULL during the insertion, not 
ic->ic_lookup.
> 	Looking at the code, it would seem that rb_parent should never
> be NULL while the node is attached.  This is, of course, what I thought
> when I checked for NULL, but I can't see different in the code.
>   
In rb_erase, you can see that the code already handle the condition when 
the removed entry's rb_parent is NULL.
> 	I could very well be wrong, however.  Can you send me info on
> the test case with the problem?  Or if you see where it happens in
> kernel-rbtree.c, can you describe it?
>   
The test case should be very simple. You just need to erase the root. 
Maybe you just need to initialize the cache,  call io_cache_insert, 
io_cache_disconnect and io_cache_insert with the same block num. The 
second insert should be fail since the disconnect will not remove the 
block and you want to insert for a second time.