diff options
author | David Woodhouse <dwmw2@infradead.org> | 2008-04-22 23:54:38 +0100 |
---|---|---|
committer | David Woodhouse <dwmw2@infradead.org> | 2008-04-22 23:54:38 +0100 |
commit | 014b164e1392a166fe96e003d2f0e7ad2e2a0bb7 (patch) | |
tree | fec4eb1a16160e3b16faa567e0fa8bcb2cb21607 /drivers/ps3 | |
parent | cf9d1e428cc28ef5798aeda0822a6ce64849a439 (diff) | |
download | op-kernel-dev-014b164e1392a166fe96e003d2f0e7ad2e2a0bb7.zip op-kernel-dev-014b164e1392a166fe96e003d2f0e7ad2e2a0bb7.tar.gz |
[JFFS2] Fix free space leak with in-band cleanmarkers
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.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Diffstat (limited to 'drivers/ps3')
0 files changed, 0 insertions, 0 deletions