Re: JFFS2 & SMP

[Estelle HAMMACHE <estelle.hammache@st.com>]

Hello Artem,

Have you made any progress with this issue ?

I believe this problem could be reproduced more easily
by adding a long sleep() at the end of __jffs2_flush_wbuf
between memset() and the affectation of c->wbuf_ofs.
Then write and fsync a file and try to read it back during
the sleep.
I've done something similar on my non-linux setup (actually
I use a longjmp to exit from __jffs2_flush_wbuf) and I obtain 
the following when I try to read back the file:
<7>Node read from 00080160: node_crc ffffffff, calculated CRC f09e7845. dsize ffffffff, csize ffffffff, offset ffffffff,
buf 1100a48
<4>Node CRC ffffffff != calculated CRC f09e7845 for node at 00080160

I think the wbuf variables are well protected against
cuncurrent writes, however if the wbuf is being flushed 
(fsync or GC) and you try to _read_ the file which has a 
node in wbuf, there may be some inconsistency between 
wbuf_ofs and wbuf contents.
I suggest to modify the end of __jffs2_flush_wbuf this way:

	c->wbuf_len = 0; /* do this FIRST so that reads won't attempt to use wbuf */
	memset(c->wbuf,0xff,c->wbuf_pagesize);
	/* adjust write buffer offset, else we get a non contiguous write bug */
	c->wbuf_ofs += c->wbuf_pagesize;

Does this seem useful ?
Estelle

"Artem B. Bityuckiy" wrote:
> 
> Hello,
> 
> how the the wbuf and related variables in the jffs2_sb_info are protected?
> 
> --
> Best Regards,
> Artem B. Bityuckiy,
> St.-Petersburg, Russia.
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 
Estelle Hammache
Terminal Management Team (Mobile phones MCU Software Development)
TINA : 044 8024
Phone : (+33) 1 58 07 80 24