summaryrefslogtreecommitdiffstats
path: root/drivers/ps3
diff options
context:
space:
mode:
authorDavid Woodhouse <dwmw2@infradead.org>2008-04-22 23:54:38 +0100
committerDavid Woodhouse <dwmw2@infradead.org>2008-04-22 23:54:38 +0100
commit014b164e1392a166fe96e003d2f0e7ad2e2a0bb7 (patch)
treefec4eb1a16160e3b16faa567e0fa8bcb2cb21607 /drivers/ps3
parentcf9d1e428cc28ef5798aeda0822a6ce64849a439 (diff)
downloadop-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
OpenPOWER on IntegriCloud