block_cache

Hi there,

while trying to hunt bug #2634 I found that:

1 - We don't check for the correct registration of low memory handler
in the block_cache constructor, which can fail (the registration) due to luck
of memory. I don't know how problematic is that, just wanted to
pointed it out ;-)

2 - There seem to be an useless check in the get_next_locked_block_cache,

-               if (cache->deleting) {
-                       mutex_unlock(&cache->lock);
-                       continue;
-               }

that's after gainig the lock of the cache. The deleting flag on the other hand,
it's only set when calling the block_cache destructor, which happens
in case the constructor
fails, in which case the block_cache is now not even in the sCacheList
(and before the mutex itself
wouldn't even been initiliazed), and in block_cache_delete, but in
this case we first gain the lock of
the cache before calling the destructor. So unless I'm missing
something else (which might be the case)
the check can be safely removed. ;-)

Anyway, as for the bug itself, it's clearly due to a cache_block with
a NULL hash pointer, which
at first I thought could be related to bug #2631, but now I'm pretty
sure it's not, because the lock
of the cache is gained before using the hash pointer, and therefore it
should have crashed in mutex_lock
if not correctly initialized.

If you have any hints please let me know! ;-)

Regards,
-- 
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer Engineer
University of Pisa
www.haiku-os.it

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/