[PATCH][JFFS2] Fix garbage collector block search

[Jörn Engel]

[ I have already written a reply, but somehow that got lost.  Sorry
about the delay. ]

On Fri, 18 January 2008 19:28:08 +0300, Alexander Belyakov wrote:
> On 1/15/08, Jörn Engel <joern at logfs.org> wrote:
> >
> > Right now the important thing is to dig deeper and understand the nature
> > of this bug.  You can reproduce it, that is good.  We also know that it
> > makes a difference whether the block is on one list or the other.  But
> > we don't know yet, what difference exactly it makes.
> 
> Question. What is success criteria for jffs2_garbage_collect_pass() execution?
> 
> Why asking? In the case described above jffs2_find_gc_block() fails to
> find erase block for garbage collection but falling into
> jffs2_flush_wbuf_pad(c) which produces amount of erasing blocks. So
> jffs2_garbage_collect_pass() sees no single block for garbage
> collection, but filesystem still recieves fresh erasing blocks upon
> execution.
> 
> Is it success or failure? Theoretically.

Maybe the best answer to this is in jffs2_do_reserve_space:
        /* this needs a little more thought (true <tglx> :)) */

The exit criterium of jffs2_do_reserve_space() should be one of a)
enough free space was found or b) there is not enough free space.  If
the function returns with b) while there actually is more space to be
freed by calling jffs2_flush_wbuf_pad(), that is a bug.

Is this the case?  If it is, there should be blocks on the
erasable_pending_wbuf_list.  And that case is handled (correctly at
first glance) in jffs2_find_nextblock.

That is about as much digging as I will do.  My personal interest is
more in replacing JFFS2 than hunting arcane bugs in it. ;)

Jörn

-- 
And spam is a useful source of entropy for /dev/random too!
-- Jasmine Strong