summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorDavid Woodhouse <dwmw2@infradead.org>2008-04-23 00:54:38 +0200
committerDavid Woodhouse <dwmw2@infradead.org>2008-04-23 00:54:38 +0200
commit014b164e1392a166fe96e003d2f0e7ad2e2a0bb7 (patch)
treefec4eb1a16160e3b16faa567e0fa8bcb2cb21607 /include
parent[JFFS2] Self-sufficient #includes in jffs2_fs_i.h: include <linux/mutex.h> (diff)
downloadlinux-014b164e1392a166fe96e003d2f0e7ad2e2a0bb7.tar.xz
linux-014b164e1392a166fe96e003d2f0e7ad2e2a0bb7.zip
[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 'include')
0 files changed, 0 insertions, 0 deletions