1. 05 Oct, 2010 1 commit
    • Jan Kara's avatar
      ext3: Fix lost extented attributes for inode with ino == 11 · beb37b85
      Jan Kara authored
      
      If a filesystem has inode size > 128 and someone deletes lost+found and
      reuses inode 11 for some other file, extented attributes set for this
      inode before umount will get lost after remounting the filesystem. This
      is because extended attributes will get stored in an inode but ext3_iget
      will ignore them due to workaround of a bug in an old mkfs.
      
      Fix the problem by initializing i_extra_isize to 0 for freshly allocated
      inodes where mkfs workaround in ext3_iget applies. This way these inodes
      will always store extended attributes in a special block and no problems
      occur.
      
      The bug was spotted and a reproduction test provided by:
        Masayoshi MIZUMA <m.mizuma@jp.fujitsu.com>
      Reviewed-by: default avatarAndreas Dilger <adilger.kernel@dilger.ca>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      beb37b85
  2. 09 Aug, 2010 1 commit
  3. 21 May, 2010 1 commit
  4. 29 Mar, 2010 1 commit
    • Linus Torvalds's avatar
      ext3: fix broken handling of EXT3_STATE_NEW · de329820
      Linus Torvalds authored
      In commit 9df93939 ("ext3: Use bitops to read/modify
      EXT3_I(inode)->i_state") ext3 changed its internal 'i_state' variable to
      use bitops for its state handling.  However, unline the same ext4
      change, it didn't actually change the name of the field when it changed
      the semantics of it.
      
      As a result, an old use of 'i_state' remained in fs/ext3/ialloc.c that
      initialized the field to EXT3_STATE_NEW.  And that does not work
      _at_all_ when we're now working with individually named bits rather than
      values that get masked.  So the code tried to mark the state to be new,
      but in actual fact set the field to EXT3_STATE_JDATA.  Which makes no
      sense at all, and screws up all the code that checks whether the inode
      was newly allocated.
      
      In particular, it made the xattr code unhappy, and caused various random
      behavior, like apparently
      
      	https://bugzilla.redhat.com/show_bug.cgi?id=577911
      
      
      
      So fix the initialization, and rename the field to match ext4 so that we
      don't have this happen again.
      
      Cc: James Morris <jmorris@namei.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Daniel J Walsh <dwalsh@redhat.com>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      de329820
  5. 04 Mar, 2010 3 commits
    • Christoph Hellwig's avatar
      dquot: cleanup dquot initialize routine · 871a2931
      Christoph Hellwig authored
      
      Get rid of the initialize dquot operation - it is now always called from
      the filesystem and if a filesystem really needs it's own (which none
      currently does) it can just call into it's own routine directly.
      
      Rename the now static low-level dquot_initialize helper to __dquot_initialize
      and vfs_dq_init to dquot_initialize to have a consistent namespace.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      871a2931
    • Christoph Hellwig's avatar
      dquot: cleanup dquot drop routine · 9f754758
      Christoph Hellwig authored
      
      Get rid of the drop dquot operation - it is now always called from
      the filesystem and if a filesystem really needs it's own (which none
      currently does) it can just call into it's own routine directly.
      
      Rename the now static low-level dquot_drop helper to __dquot_drop
      and vfs_dq_drop to dquot_drop to have a consistent namespace.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      9f754758
    • Christoph Hellwig's avatar
      dquot: cleanup inode allocation / freeing routines · 63936dda
      Christoph Hellwig authored
      
      Get rid of the alloc_inode and free_inode dquot operations - they are
      always called from the filesystem and if a filesystem really needs
      their own (which none currently does) it can just call into it's
      own routine directly.
      
      Also get rid of the vfs_dq_alloc/vfs_dq_free wrappers and always
      call the lowlevel dquot_alloc_inode / dqout_free_inode routines
      directly, which now lose the number argument which is always 1.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      63936dda
  6. 11 Jun, 2009 1 commit
  7. 25 Mar, 2009 1 commit
  8. 08 Jan, 2009 2 commits
  9. 31 Dec, 2008 1 commit
  10. 13 Nov, 2008 1 commit
  11. 25 Jul, 2008 1 commit
  12. 28 Apr, 2008 1 commit
  13. 21 Apr, 2008 1 commit
  14. 08 Feb, 2008 1 commit
  15. 07 Feb, 2008 1 commit
  16. 17 Oct, 2007 1 commit
  17. 27 Sep, 2006 3 commits
  18. 25 Jun, 2006 1 commit
    • Mingming Cao's avatar
      [PATCH] ext3_fsblk_t: filesystem, group blocks and bug fixes · 1c2bf374
      Mingming Cao authored
      Some of the in-kernel ext3 block variable type are treated as signed 4 bytes
      int type, thus limited ext3 filesystem to 8TB (4kblock size based).  While
      trying to fix them, it seems quite confusing in the ext3 code where some
      blocks are filesystem-wide blocks, some are group relative offsets that need
      to be signed value (as -1 has special meaning).  So it seem saner to define
      two types of physical blocks: one is filesystem wide blocks, another is
      group-relative blocks.  The following patches clarify these two types of
      blocks in the ext3 code, and fix the type bugs which limit current 32 bit ext3
      filesystem limit to 8TB.
      
      With this series of patches and the percpu counter data type changes in the mm
      tree, we are able to extend exts filesystem limit to 16TB.
      
      This work is also a pre-request for the recent >32 bit ext3 work, and makes
      the kernel to able to address 48 bit ext3 block a lot easier: Simply redefine
      ext3_fsblk_t from unsigned long to sector_t and redefine the format string for
      ext3 filesystem block corresponding.
      
      Two RFC with a series patches have been posted to ext2-devel list and have
      been reviewed and discussed:
      http://marc.theaimsgroup.com/?l=ext2-devel&m=114722190816690&w=2
      
      http://marc.theaimsgroup.com/?l=ext2-devel&m=114784919525942&w=2
      
      
      
      Patches are tested on both 32 bit machine and 64 bit machine, <8TB ext3 and
      >8TB ext3 filesystem(with the latest to be released e2fsprogs-1.39).  Tests
      includes overnight fsx, tiobench, dbench and fsstress.
      
      This patch:
      
      Defines ext3_fsblk_t and ext3_grpblk_t, and the printk format string for
      filesystem wide blocks.
      
      This patch classifies all block group relative blocks, and ext3_fsblk_t blocks
      occurs in the same function where used to be confusing before.  Also include
      kernel bug fixes for filesystem wide in-kernel block variables.  There are
      some fileystem wide blocks are treated as int/unsigned int type in the kernel
      currently, especially in ext3 block allocation and reservation code.  This
      patch fixed those bugs by converting those variables to ext3_fsblk_t(unsigned
      long) type.
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1c2bf374
  19. 10 Jan, 2006 1 commit
  20. 08 Jan, 2006 1 commit
  21. 09 Nov, 2005 1 commit
  22. 30 Oct, 2005 2 commits
    • Ben Dooks's avatar
      [PATCH] ext3: sparse fixes · 381be254
      Ben Dooks authored
      
      Fix warnings from sparse due to un-declared functions that should either
      have a header file or have been declared static
      
       fs/ext2/bitmap.c:14:15: warning: symbol 'ext2_count_free' was not declared. Should it be static?
       fs/ext2/namei.c:92:15: warning: symbol 'ext2_get_parent' was not declared. Should it be static?
       fs/ext3/bitmap.c:15:15: warning: symbol 'ext3_count_free' was not declared. Should it be static?
       fs/ext3/namei.c:1013:15: warning: symbol 'ext3_get_parent' was not declared. Should it be static?
       fs/ext3/xattr.c:214:1: warning: symbol 'ext3_xattr_block_get' was not declared. Should it be static?
       fs/ext3/xattr.c:358:1: warning: symbol 'ext3_xattr_block_list' was not declared. Should it be static?
       fs/ext3/xattr.c:630:1: warning: symbol 'ext3_xattr_block_find' was not declared. Should it be static?
       fs/ext3/xattr.c:863:1: warning: symbol 'ext3_xattr_ibody_find' was not declared. Should it be static?
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      381be254
    • Glauber de Oliveira Costa's avatar
      [PATCH] Locking problems while EXT3FS_DEBUG on · 5b116879
      Glauber de Oliveira Costa authored
      
      I noticed some problems while running ext3 with the debug flag set on.
      More precisely, I was unable to umount the filesystem.  Some investigation
      took me to the patch that follows.
      
      At a first glance , the lock/unlock I've taken out seems really not
      necessary, as the main code (outside debug) does not lock the super.  The
      only additional danger operations that debug code introduces seems to be
      related to bitmap, but bitmap operations tends to be all atomic anyway.
      
      I also took the opportunity to fix 2 spelling errors.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      5b116879
  23. 28 Sep, 2005 1 commit
  24. 09 Sep, 2005 1 commit
  25. 27 Jul, 2005 1 commit
  26. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4