1. 14 Feb, 2009 2 commits
  2. 10 Feb, 2009 5 commits
    • Aneesh Kumar K.V's avatar
      ext4: Fix lockdep warning · ba443916
      Aneesh Kumar K.V authored
      We should not call ext4_mb_add_n_trim while holding alloc_semp.
      
          =============================================
          [ INFO: possible recursive locking detected ]
          2.6.29-rc4-git1-dirty #124
          ---------------------------------------------
          ffsb/3116 is trying to acquire lock:
           (&meta_group_info[i]->alloc_sem){----}, at: [<ffffffff8035a6e8>]
           ext4_mb_load_buddy+0xd2/0x343
      
          but task is already holding lock:
           (&meta_group_info[i]->alloc_sem){----}, at: [<ffffffff8035a6e8>]
           ext4_mb_load_buddy+0xd2/0x343
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12672Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      ba443916
    • Wei Yongjun's avatar
      ext4: Fix to read empty directory blocks correctly in 64k · 7be2baaa
      Wei Yongjun authored
      The rec_len field in the directory entry is 16 bits, so there was a
      problem representing rec_len for filesystems with a 64k block size in
      the case where the directory entry takes the entire 64k block.
      Unfortunately, there were two schemes that were proposed; one where
      all zeros meant 65536 and one where all ones (65535) meant 65536.
      E2fsprogs used 0, whereas the kernel used 65535.  Oops.  Fortunately
      this case happens extremely rarely, with the most common case being
      the lost+found directory, created by mke2fs.
      
      So we will be liberal in what we accept, and accept both encodings,
      but we will continue to encode 65536 as 65535.  This will require a
      change in e2fsprogs, but with fortunately ext4 filesystems normally
      have the dir_index feature enabled, which precludes having a
      completely empty directory block.
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      7be2baaa
    • Jan Kara's avatar
      jbd2: Avoid possible NULL dereference in jbd2_journal_begin_ordered_truncate() · 7f5aa215
      Jan Kara authored
      If we race with commit code setting i_transaction to NULL, we could
      possibly dereference it.  Proper locking requires the journal pointer
      (to access journal->j_list_lock), which we don't have.  So we have to
      change the prototype of the function so that filesystem passes us the
      journal pointer.  Also add a more detailed comment about why the
      function jbd2_journal_begin_ordered_truncate() does what it does and
      how it should be used.
      
      Thanks to Dan Carpenter <error27@gmail.com> for pointing to the
      suspitious code.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Acked-by: default avatarJoel Becker <joel.becker@oracle.com>
      CC: linux-ext4@vger.kernel.org
      CC: ocfs2-devel@oss.oracle.com
      CC: mfasheh@suse.de
      CC: Dan Carpenter <error27@gmail.com>
      7f5aa215
    • Jan Kara's avatar
      Revert "ext4: wait on all pending commits in ext4_sync_fs()" · 9eddacf9
      Jan Kara authored
      This undoes commit 14ce0cb4.
      
      Since jbd2_journal_start_commit() is now fixed to return 1 when we
      started a transaction commit, there's some transaction waiting to be
      committed or there's a transaction already committing, we don't
      need to call ext4_force_commit() in ext4_sync_fs(). Furthermore
      ext4_force_commit() can unnecessarily create sync transaction which is
      expensive so it's worthwhile to remove it when we can.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12224Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: Eric Sandeen <sandeen@redhat.com>
      Cc: linux-ext4@vger.kernel.org
      9eddacf9
    • Jan Kara's avatar
      jbd2: Fix return value of jbd2_journal_start_commit() · c88ccea3
      Jan Kara authored
      The function jbd2_journal_start_commit() returns 1 if either a
      transaction is committing or the function has queued a transaction
      commit. But it returns 0 if we raced with somebody queueing the
      transaction commit as well. This resulted in ext4_sync_fs() not
      functioning correctly (description from Arthur Jones): 
      
         In the case of a data=ordered umount with pending long symlinks
         which are delayed due to a long list of other I/O on the backing
         block device, this causes the buffer associated with the long
         symlinks to not be moved to the inode dirty list in the second
         phase of fsync_super.  Then, before they can be dirtied again,
         kjournald exits, seeing the UMOUNT flag and the dirty pages are
         never written to the backing block device, causing long symlink
         corruption and exposing new or previously freed block data to
         userspace.
      
      This can be reproduced with a script created by Eric Sandeen
      <sandeen@redhat.com>:
      
              #!/bin/bash
      
              umount /mnt/test2
              mount /dev/sdb4 /mnt/test2
              rm -f /mnt/test2/*
              dd if=/dev/zero of=/mnt/test2/bigfile bs=1M count=512
              touch /mnt/test2/thisisveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongfilename
              ln -s /mnt/test2/thisisveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongfilename
              /mnt/test2/link
              umount /mnt/test2
              mount /dev/sdb4 /mnt/test2
              ls /mnt/test2/
      
      This patch fixes jbd2_journal_start_commit() to always return 1 when
      there's a transaction committing or queued for commit.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      CC: Eric Sandeen <sandeen@redhat.com>
      CC: linux-ext4@vger.kernel.org
      c88ccea3
  3. 13 Feb, 2009 33 commits