JFFS2 & SMP

[Artem B. Bityuckiy]

Estelle, I'm glad not to introduce new mutes, but I don't really know 
how to do so easy way.

 > I didn't check all the functions which
 > modify the wbuf variables so I don't know whether it is a
 > realistic idea or not.
I investigated this. These are:
jffs2_flash_writev()
__jffs2_flush_wbuf()
jffs2_wbuf_recover() too, but it is called only from __jffs2_flush_wbuf().

Anyway, all such functions are in wbuf.c

Basically, the c->alloc_sem protects the write buffer. It is logical to 
use it in the jffs2_flash_read() too. But the problem is that the 
jffs2_flash_read() is called by from many places and the c->alloc_sem 
may be already locked (when the jffs2_flash_read() is called from the 
Garbage Collector, for example) or not locked (when, for example, JFFS2 
performs the read_node() superblock operation).

Thus, we should introduce one more function parameter (like 
alloc_sem_is_set "boolean" flag) to distinguish if the alloc_sem is 
hold. It is possible too. But the jffs2_flash_read() functions is also 
called from many other functions, and we will need to add this parameter 
recursively to all of them (for example, jffs2_mark_node_obsolete()).

It seems the "down_trylock" decision is will not work.

So, I think this way is not very nice... Any suggestions?

Estelle HAMMACHE wrote:
> Hello Artem,
> 
> as I mentionned before I don't have linux so I can't really test
> your patch right now. I agree with the principle of your patch.
> I believe it should work this way.
> I was hoping the problem could be solved without introducing
> a new mutex, however I didn't check all the functions which
> modify the wbuf variables so I don't know whether it is a 
> realistic idea or not.
> bye
> Estelle
> 


-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.