[PATCH] JFFS2 race bug fix

[Artem B. Bityuckiy]

Hello,

here is the patch which fixes a JFFS2 bug related to races.

Description
~~~~~~~~~

Suppose we append something to a file.

Look at file.c:251, here JFFS2 calls jffs2_write_inode_range() which
writes new nodes.

After the node has been written, JFFS2 updates the i_size field at the
'struct inode' object (look at file.c:270) (in our example it increases
it).

Now take a glimpse a the jffs2_write_inode_range() function in
write.c:452. This function may break the peace of data to be written
into 2 smaller chunks (if there is no enough room at the current block).
After the first chunk A has been written, we free f->sem. In this point
the inode->i_size has its old value, while the real size of inode is
equivalent to the old value + the the length of node A.

Suppose we are preempted at this point and GC starts. Picks some node
belonging to our file and tries to move it, probably merge it, etc.

Garbage Collector uses the i_size value (which is, as we remember,
wrong, since it wasn't updated yet) in some places. Just do:

grep JFFS2_F_I_SIZE *
gc.c:   ri.isize = cpu_to_je32(JFFS2_F_I_SIZE(f));
gc.c:   ri.isize = cpu_to_je32(JFFS2_F_I_SIZE(f));
gc.c:           BUG_ON(end > JFFS2_F_I_SIZE(f));
gc.c:           ri.isize = cpu_to_je32(JFFS2_F_I_SIZE(f));
os-linux.h:#define JFFS2_F_I_SIZE(f) (OFNI_EDONI_2SFFJ(f)->i_size)

So, in this case it may write nodes with wrong ri.isize and have
problems later.

Personally I hit on BUG_ON(end > JFFS2_F_I_SIZE(f)) at gc:1171 when I
tested JFFS2 on an SMP host with preemption enabled.

Here is the proposed patch, please, review.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jffs2-smp-1.diff
Type: text/x-patch
Size: 2564 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050408/f5df6351/attachment.bin