Bug 652013

Created attachment 459527 [details]
proposed patch

Just as a general note, using the ext4 driver for ext3 filesystems in RHEL6 is not recommended.  We can fix this, but it's not the preferred mode of operation.

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Upstream commit:

commit e0d10bfa91b0a089a9e2c378b5c42f4e96171d95
Author: Toshiyuki Okajima <toshi.okajima.com>
Date:   Wed Oct 27 21:30:06 2010 -0400

    ext4: improve llseek error handling for overly large seek offsets
    
    The llseek system call should return EINVAL if passed a seek offset
    which results in a write error.  What this maximum offset should be
    depends on whether or not the huge_file file system feature is set,
    and whether or not the file is extent based or not.
    
    
    If the file has no "EXT4_EXTENTS_FL" flag, the maximum size which can be
    written (write systemcall) is different from the maximum size which can be
    sought (lseek systemcall).
    
    For example, the following 2 cases demonstrates the differences
    between the maximum size which can be written, versus the seek offset
    allowed by the llseek system call:
    
    #1: mkfs.ext3 <dev>; mount -t ext4 <dev>
    #2: mkfs.ext3 <dev>; tune2fs -Oextent,huge_file <dev>; mount -t ext4 <dev>
    
    Table. the max file size which we can write or seek
           at each filesystem feature tuning and file flag setting
    +============+===============================+===============================+
    | \ File flag|                               |                               |
    |      \     |     !EXT4_EXTENTS_FL          |        EXT4_EXTETNS_FL        |
    |case       \|                               |                               |
    +------------+-------------------------------+-------------------------------+
    | #1         |   write:      2194719883264   | write:       --------------   |
    |            |   seek:       2199023251456   | seek:        --------------   |
    +------------+-------------------------------+-------------------------------+
    | #2         |   write:      4402345721856   | write:       17592186044415   |
    |            |   seek:      17592186044415   | seek:        17592186044415   |
    +------------+-------------------------------+-------------------------------+
    
    The differences exist because ext4 has 2 maxbytes which are sb->s_maxbytes
    (= extent-mapped maxbytes) and EXT4_SB(sb)->s_bitmap_maxbytes (= block-mapped
    maxbytes).  Although generic_file_llseek uses only extent-mapped maxbytes.
    (llseek of ext4_file_operations is generic_file_llseek which uses
    sb->s_maxbytes.)
    
    Therefore we create ext4 llseek function which uses 2 maxbytes.
    
    The new own function originates from generic_file_llseek().
    If the file flag, "EXT4_EXTENTS_FL" is not set, the function alters
    inode->i_sb->s_maxbytes into EXT4_SB(inode->i_sb)->s_bitmap_maxbytes.
    
    Signed-off-by: Toshiyuki Okajima <toshi.okajima.com>

I think that there is an error in the attached backported patch:

+	if (!(inode->i_flags & EXT4_EXTENTS_FL))
+		maxbytes = EXT4_SB(inode->i_sb)->s_bitmap_maxbytes;
+	else
+		maxbytes = inode->i_sb->s_maxbytes;

upstream this is:

+       if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)))
+               maxbytes = EXT4_SB(inode->i_sb)->s_bitmap_maxbytes;
+       else
+               maxbytes = inode->i_sb->s_maxbytes;

but the ext4_test_inode_flag function is not yet available in rhel6.

However, it should be changed to:

+	if (!(EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL))

not

+	if (!(inode->i_flags & EXT4_EXTENTS_FL))

because the EXT4_EXTENTS_FL flag is only valid on the extended ext4 inode not the vfs inode.

Patch(es) available on kernel-2.6.32-91.el6

Reproduced in 2.6.32-90.el6 and verified in 2.6.32-91.el.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0542.html