Description of problem:

David Woodhouse has posted patch for the following issue into the 2.6.24.
stable version of the upstream kernel: 

<cite>

We were accounting for the cleanmarker by calling jffs2_link_node_ref()
(without locking!), which adjusted both superblock and per-eraseblock
accounting, subtracting the size of the cleanmarker from {jeb,c}->free_size
and adding it to {jeb,c}->used_size.

But only _then_ were we adding the size of the newly-erased block back
to the superblock counts, and we were adding each of jeb->{free,used}_size
to the corresponding superblock counts. Thus, the size of the cleanmarker
was effectively subtracted from the superblock's free_size _twice_.

Fix this, by always adding a full eraseblock size to c->free_size when
we've erased a block. And call jffs2_link_node_ref() under the proper
lock, while we're at it.

Thanks to Alexander Yurchenko and/or Damir Shayhutdinov for (almost)
pinpointing the problem.

</cite>

This issue also present in RHEL-5 kernel -- introduced by:
commit f1f9671bd8f7d2ac6a918bad806ab5bdc0daaf4e
Author: David Woodhouse <dwmw2>
Date:   Sat May 20 19:45:26 2006 +0100

Version-Release number of selected component (if applicable):
2.6.18-53.el5 and higher

How reproducible:
Always

Steps to Reproduce:
1. No reproducer
2.
3.
  
Actual results:
The block size is acconted 2 times.

Expected results:
The block sizes to be accounted correctly (only one time).

Additional info:

Proposed upstream patch: (2.6.24.6 backport):

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=blobdiff;f=fs/jffs2/erase.c;h=bdc6a7bec802ad1b8f387bd8b47270c0f32d600e;hp=96d9ad56e57303662f5165f02d97b00b9d7c8960;hb=014b164e1392a166fe96e003d2f0e7ad2e2a0bb7;hpb=cf9d1e428cc28ef5798aeda0822a6ce64849a439