Bug 519471

Summary: ext4 bitmap allocator must limit blocks to < 2^32
Product: Red Hat Enterprise Linux 6 Reporter: Valerie Aurora Henson <vaurora>
Component: kernelAssignee: Eric Sandeen <esandeen>
Status: CLOSED CURRENTRELEASE QA Contact: Igor Zhang <yugzhang>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: esandeen, rwheeler, vaurora, yugzhang
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: kernel-2.6.32-1.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-15 14:24:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 534150    

Description Valerie Aurora Henson 2009-08-26 18:06:07 UTC
This is a tracking bug for an ext4 kernel bugzilla:

http://bugzilla.kernel.org/show_bug.cgi?id=9502

Comment 2 RHEL Program Management 2009-08-26 18:46:30 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Eric Sandeen 2009-11-13 22:15:14 UTC
Upstream in 2.6.32:

commit fb0a387dcdcd21aab1b09ee7fd80b7c979bdbbfd
Author: Eric Sandeen <sandeen>
Date:   Wed Sep 16 14:45:10 2009 -0400

    ext4: limit block allocations for indirect-block files to < 2^32
    
    Today, the ext4 allocator will happily allocate blocks past
    2^32 for indirect-block files, which results in the block
    numbers getting truncated, and corruption ensues.
    
    This patch limits such allocations to < 2^32, and adds
    BUG_ONs if we do get blocks larger than that.
    
    This should address RH Bug 519471, ext4 bitmap allocator
    must limit blocks to < 2^32
    
    * ext4_find_goal() is modified to choose a goal < UINT_MAX,
      so that our starting point is in an acceptable range.
    
    * ext4_xattr_block_set() is modified such that the goal block
      is < UINT_MAX, as above.
    
    * ext4_mb_regular_allocator() is modified so that the group
      search does not continue into groups which are too high
    
    * ext4_mb_use_preallocated() has a check that we don't use
      preallocated space which is too far out
    
    * ext4_alloc_blocks() and ext4_xattr_block_set() add some BUG_ONs
    
    No attempt has been made to limit inode locations to < 2^32,
    so we may wind up with blocks far from their inodes.  Doing
    this much already will lead to some odd ENOSPC issues when the
    "lower 32" gets full, and further restricting inodes could
    make that even weirder.
    
    For high inodes, choosing a goal of the original, % UINT_MAX,
    may be a bit odd, but then we're in an odd situation anyway,
    and I don't know of a better heuristic.
    
    Signed-off-by: Eric Sandeen <sandeen>
    Signed-off-by: "Theodore Ts'o" <tytso>

Comment 5 Igor Zhang 2010-09-30 06:39:28 UTC
There are no separate patches for this bug in kernel-2.6.32-1.el6.
Sanity Check the corresponding code in kernel-2.6.32-73.el6 and make comparison with kernel-2.6.32-1.el6.
Two BUG_ONs in inode.c are replaced by as much as following code:
	if (unlikely(current_block + ar.len > EXT4_MAX_BLOCK_FILE_PHYS)) {
		EXT4_ERROR_INODE(inode,
				 "current_block %llu + ar.len %d > %d!",
				 current_block, ar.len,
				 EXT4_MAX_BLOCK_FILE_PHYS);
		*err = -EIO;
		goto failed_out;
	}

The last BUG_ON(block > EXT4_MAX_BLOCK_FILE_PHYS) in xattr.c is still there.

Comment 6 releng-rhel@redhat.com 2010-11-15 14:24:29 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.