1. 10 Jan, 2011 1 commit
  2. 19 Dec, 2010 1 commit
  3. 27 Oct, 2010 1 commit
    • Toshiyuki Okajima's avatar
      ext4: improve llseek error handling for overly large seek offsets · e0d10bfa
      Toshiyuki Okajima authored
      
      
      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: default avatarToshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      e0d10bfa
  4. 27 Jul, 2010 3 commits
  5. 14 Jun, 2010 1 commit
  6. 16 May, 2010 3 commits
  7. 04 Mar, 2010 1 commit
  8. 01 Mar, 2010 1 commit
  9. 15 Feb, 2010 1 commit
  10. 13 May, 2009 2 commits
  11. 14 Feb, 2009 1 commit
    • Wei Yongjun's avatar
      ext4: New rec_len encoding for very large blocksizes · 3d0518f4
      Wei Yongjun authored
      
      
      The rec_len field in the directory entry is 16 bits, so to encode
      blocksizes larger than 64k becomes problematic.  This patch allows us
      to supprot block sizes up to 256k, by using the low 2 bits to extend
      the range of rec_len to 2**18-1 (since valid rec_len sizes must be a
      multiple of 4).  We use the convention that a rec_len of 0 or 65535
      means the filesystem block size, for compatibility with older kernels.
      
      It's unlikely we'll see VM pages of up to 256k, but at some point we
      might find that the Linux VM has been enhanced to support filesystem
      block sizes > than the VM page size, at which point it might be useful
      for some applications to allow very large filesystem block sizes.
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      3d0518f4
  12. 05 Jan, 2009 1 commit
  13. 04 Nov, 2008 1 commit
    • Theodore Ts'o's avatar
      ext4: Change unsigned long to unsigned int · 498e5f24
      Theodore Ts'o authored
      
      
      Convert the unsigned longs that are most responsible for bloating the
      stack usage on 64-bit systems.
      
      Nearly all places in the ext3/4 code which uses "unsigned long" is
      probably a bug, since on 32-bit systems a ulong a 32-bits, which means
      we are wasting stack space on 64-bit systems.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      498e5f24
  14. 25 Oct, 2008 1 commit
  15. 09 Oct, 2008 1 commit
    • Eric Sandeen's avatar
      ext4: Avoid printk floods in the face of directory corruption · 9d9f1775
      Eric Sandeen authored
      
      
      Note: some people thinks this represents a security bug, since it
      might make the system go away while it is printing a large number of
      console messages, especially if a serial console is involved.  Hence,
      it has been assigned CVE-2008-3528, but it requires that the attacker
      either has physical access to your machine to insert a USB disk with a
      corrupted filesystem image (at which point why not just hit the power
      button), or is otherwise able to convince the system administrator to
      mount an arbitrary filesystem image (at which point why not just
      include a setuid shell or world-writable hard disk device file or some
      such).  Me, I think they're just being silly. --tytso
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-ext4@vger.kernel.org
      Cc: Eugene Teo <eugeneteo@kernel.sg>
      9d9f1775
  16. 08 Sep, 2008 2 commits
  17. 19 Aug, 2008 1 commit
  18. 14 Jul, 2008 1 commit
    • Mingming Cao's avatar
      ext4: delayed allocation ENOSPC handling · d2a17637
      Mingming Cao authored
      
      
      This patch does block reservation for delayed
      allocation, to avoid ENOSPC later at page flush time.
      
      Blocks(data and metadata) are reserved at da_write_begin()
      time, the freeblocks counter is updated by then, and the number of
      reserved blocks is store in per inode counter.
              
      At the writepage time, the unused reserved meta blocks are returned
      back. At unlink/truncate time, reserved blocks are properly released.
      
      Updated fix from  Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      to fix the oldallocator block reservation accounting with delalloc, added
      lock to guard the counters and also fix the reservation for meta blocks.
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      d2a17637
  19. 11 Jul, 2008 1 commit
  20. 29 Apr, 2008 2 commits
  21. 25 Feb, 2008 1 commit
  22. 28 Jan, 2008 2 commits
    • Aneesh Kumar K.V's avatar
      ext4: Introduce ext4_lblk_t · 725d26d3
      Aneesh Kumar K.V authored
      
      
      This patch adds a new data type ext4_lblk_t to represent
      the logical file blocks.
      
      This is the preparatory patch to support large files in ext4
      The follow up patch with convert the ext4_inode i_blocks to
      represent the number of blocks in file system block size. This
      changes makes it possible to have a block number 2**32 -1 which
      will result in overflow if the block number is represented by
      signed long. This patch convert all the block number to type
      ext4_lblk_t which is typedef to __u32
      
      Also remove dead code ext4_ext_walk_space
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      725d26d3
    • Jan Kara's avatar
      ext4: Avoid rec_len overflow with 64KB block size · a72d7f83
      Jan Kara authored
      
      
      With 64KB blocksize, a directory entry can have size 64KB which does not fit
      into 16 bits we have for entry lenght. So we store 0xffff instead and convert
      value when read from / written to disk. The patch also converts some places
      to use ext4_next_entry() when we are changing them anyway.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      a72d7f83
  23. 17 Oct, 2007 2 commits
  24. 16 Oct, 2007 1 commit
  25. 19 Jul, 2007 2 commits
  26. 08 May, 2007 1 commit
  27. 08 Dec, 2006 1 commit
  28. 07 Dec, 2006 1 commit
    • Eric Sandeen's avatar
      [PATCH] handle ext4 directory corruption better · e6c40211
      Eric Sandeen authored
      I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
      http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz
      
      
      
      Basically it makes a filesystem, splats some random bits over it, then
      tries to mount it and do some simple filesystem actions.
      
      At best, the filesystem catches the corruption gracefully.  At worst,
      things spin out of control.
      
      As you might guess, we found a couple places in ext4 where things spin out
      of control :)
      
      First, we had a corrupted directory that was never checked for
      consistency...  it was corrupt, and pointed to another bad "entry" of
      length 0.  The for() loop looped forever, since the length of
      ext4_next_entry(de) was 0, and we kept looking at the same pointer over and
      over and over and over...  I modeled this check and subsequent action on
      what is done for other directory types in ext4_readdir...
      
      (adding this check adds some computational expense; I am testing a followup
      patch to reduce the number of times we check and re-check these directory
      entries, in all cases.  Thanks for the idea, Andreas).
      
      Next we had a root directory inode which had a corrupted size, claimed to
      be > 200M on a 4M filesystem.  There was only really 1 block in the
      directory, but because the size was so large, readdir kept coming back for
      more, spewing thousands of printk's along the way.
      
      Per Andreas' suggestion, if we're in this read error condition and we're
      trying to read an offset which is greater than i_blocks worth of bytes,
      stop trying, and break out of the loop.
      
      With these two changes fsfuzz test survives quite well on ext4.
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e6c40211
  29. 11 Oct, 2006 2 commits