Nick Piggin wrote:
quoted text
> On Tuesday 12 August 2008 08:40, Ryan Hope wrote:
>   
>> This was item #14 on the todo list for reiser4 inclusion in mainline:
>>     

No. This patch is a nonsense.
Where did you see  radix-tree dirty tagging here?


quoted text
>> diff --git a/fs/reiser4/page_cache.c b/fs/reiser4/page_cache.c
>> index fe71368..a662c25 100644
>> --- a/fs/reiser4/page_cache.c
>> +++ b/fs/reiser4/page_cache.c
>> @@ -467,15 +467,14 @@ int reiser4_set_page_dirty_internal(struct page
>> *page) BUG_ON(mapping == NULL);
>>
>>   	if (!TestSetPageDirty(page)) {
>> +		spin_lock_irq(&mapping->tree_lock);
>>   		if (mapping_cap_account_dirty(mapping))
>>   			inc_zone_page_state(page, NR_FILE_DIRTY);
>> -
>> +		radix_tree_tag_set(&mapping->page_tree,
>> +			page_index(page), PAGECACHE_TAG_DIRTY);
>>   		__mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
>> +		spin_unlock_irq(&mapping->tree_lock);
>>   	}
>> -
>> -	/* znode must be dirty ? */
>> -	if (mapping->host == reiser4_get_super_fake(mapping->host->i_sb))
>> -		assert("", JF_ISSET(jprivate(page), JNODE_DIRTY));
>>   	return 0;
>>   }
>>     
>
> Any reason why this can't use a generic function such as
> __set_page_dirty_nobuffers? 

Currently reiser4 is working around "anonymous" pages dirtied
outside of reiser4 context (e.g. via mmap), where some reiser4
specific work (jnode creation, capturing by an atom) can not
be done.

quoted text
> There are accounting changes gone in
> there now which I suspetc may be wrong now in reiser4 (eg. task
> io accounting).
>   

Yes, this is definitely wrong. Thanks for pointing this out.
Such poking around vfs internals should be fixed, otherwise we'll
have permanent problems.

I have cc-ed Vladimir: maybe he has some hints. At least, I know
that he looked at this problem..

Thanks,
Edward.

quoted text
> Actually every site that does a radix_tree_operation there should
> be reviewed to try to use core functoins.
>
>   

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/