JFFS2 & SMP
Estelle HAMMACHE
estelle.hammache at st.com
Tue Nov 2 09:31:52 EST 2004
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
More information about the linux-mtd
mailing list