Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 444960 - kernel: JFFS2: Fix free space leak with in-band cleanmarkers
kernel: JFFS2: Fix free space leak with in-band cleanmarkers
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Josef Bacik
Red Hat Kernel QE team
Depends On:
Blocks: 533192
  Show dependency treegraph
Reported: 2008-05-02 07:48 EDT by Jan Lieskovsky
Modified: 2012-06-07 10:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-07 10:40:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
backported patch (1.37 KB, patch)
2008-05-06 10:28 EDT, Josef Bacik
no flags Details | Diff

  None (edit)
Description Jan Lieskovsky 2008-05-02 07:48:04 EDT
Description of problem:

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


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.


This issue also present in RHEL-5 kernel -- introduced by:
commit f1f9671bd8f7d2ac6a918bad806ab5bdc0daaf4e
Author: David Woodhouse <dwmw2@infradead.org>
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:

Steps to Reproduce:
1. No reproducer
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: ( backport):

Comment 1 Josef Bacik 2008-05-06 10:28:46 EDT
Created attachment 304635 [details]
backported patch

Here is the backported patch.  Please test this, as all of my boxes are in use
for EXT4 stuff I don't have something to even compile this on.	Thanks much.
Comment 3 RHEL Product and Program Management 2009-02-16 10:42:40 EST
Updating PM score.
Comment 5 Josef Bacik 2009-07-02 11:19:39 EDT
moving to 5.5, still waiting on confirmation that the problem is fixed.

Note You need to log in before you can comment on or make changes to this bug.