This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git. Pull mirroring updated .
  1. 10 Feb, 2008 1 commit
    • Jan Kara's avatar
      ext4: Fix Direct I/O locking · 7fb5409d
      Jan Kara authored
      
      
      We cannot start transaction in ext4_direct_IO() and just let it last
      during the whole write because dio_get_page() acquires mmap_sem which
      ranks above transaction start (e.g. because we have dependency chain
      mmap_sem->PageLock->journal_start, or because we update atime while
      holding mmap_sem) and thus deadlocks could happen. We solve the problem
      by starting a transaction separately for each ext4_get_block() call.
      
      We *could* have a problem that we allocate a block and before its data
      are written out the machine crashes and thus we expose stale data. But
      that does not happen because for hole-filling generic code falls back to
      buffered writes and for file extension, we add inode to orphan list and
      thus in case of crash, journal replay will truncate inode back to the
      original size.
      
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      7fb5409d
  2. 06 Feb, 2008 1 commit
    • Eric Sandeen's avatar
      allow in-inode EAs on ext4 root inode · 0040d987
      Eric Sandeen authored
      
      
      The ext3 root inode was treated specially with respect
      to in-inode extended attributes, for reasons detailed
      in the removed comment below.  The first mkfs-created
      inodes would not get extra_i_size or the EXT3_STATE_XATTR
      flag set in ext3_read_inode, which disallowed reading or
      setting in-inode EAs on the root.
      
      However, in ext4, ext4_mark_inode_dirty calls
      ext4_expand_extra_isize for all inodes; once this is done
      EAs may be placed in the root ext4 inode body.
      
      But for reasons above, it won't be found after a reboot.
      
      testcase:
      
      setfattr -n user.name -v value mntpt/
      setfattr -n user.name2 -v value2 mntpt/
      umount mntpt/; remount mntpt/
      getfattr -d mntpt/
      
      name2/value2 has gone missing; debugfs shows it in the
      inode body, but it is not found there by getattr.
      
      The following fixes it up; newer mkfs appears to properly
      zero the inodes, so this workaround isn't needed for ext4.
      
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      0040d987
  3. 07 Feb, 2008 1 commit
  4. 06 Feb, 2008 1 commit
  5. 05 Feb, 2008 1 commit
    • Christoph Lameter's avatar
      Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user · eebd2aa3
      Christoph Lameter authored
      
      
      Simplify page cache zeroing of segments of pages through 3 functions
      
      zero_user_segments(page, start1, end1, start2, end2)
      
              Zeros two segments of the page. It takes the position where to
              start and end the zeroing which avoids length calculations and
      	makes code clearer.
      
      zero_user_segment(page, start, end)
      
              Same for a single segment.
      
      zero_user(page, start, length)
      
              Length variant for the case where we know the length.
      
      We remove the zero_user_page macro. Issues:
      
      1. Its a macro. Inline functions are preferable.
      
      2. The KM_USER0 macro is only defined for HIGHMEM.
      
         Having to treat this special case everywhere makes the
         code needlessly complex. The parameter for zeroing is always
         KM_USER0 except in one single case that we open code.
      
      Avoiding KM_USER0 makes a lot of code not having to be dealing
      with the special casing for HIGHMEM anymore. Dealing with
      kmap is only necessary for HIGHMEM configurations. In those
      configurations we use KM_USER0 like we do for a series of other
      functions defined in highmem.h.
      
      Since KM_USER0 is depends on HIGHMEM the existing zero_user_page
      function could not be a macro. zero_user_* functions introduced
      here can be be inline because that constant is not used when these
      functions are called.
      
      Also extract the flushing of the caches to be outside of the kmap.
      
      [akpm@linux-foundation.org: fix nfs and ntfs build]
      [akpm@linux-foundation.org: fix ntfs build some more]
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: Michael Halcrow <mhalcrow@us.ibm.com>
      Cc: <linux-ext4@vger.kernel.org>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Mark Fasheh <mark.fasheh@oracle.com>
      Cc: David Chinner <dgc@sgi.com>
      Cc: Michael Halcrow <mhalcrow@us.ibm.com>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      eebd2aa3
  6. 29 Jan, 2008 13 commits
  7. 17 Oct, 2007 3 commits
  8. 16 Oct, 2007 1 commit
  9. 19 Jul, 2007 1 commit
    • Mingming Cao's avatar
      fix ext4/JBD2 build warnings · b38bd33a
      Mingming Cao authored
      Looking at the current linus-git tree jbd_debug() define in
      include/linux/jbd2.h
      
      extern u8 journal_enable_debug;
      
      #define jbd_debug(n, f, a...)                                           \
              do {                                                            \
                      if ((n) <= journal_enable_debug) {                      \
                              printk (KERN_DEBUG "(%s, %d): %s: ",            \
                                      __FILE__, __LINE__, __FUNCTION__);      \
                              printk (f, ## a);                               \
                      }                                                       \
              } while (0)
      > fs/ext4/inode.c: In function ‘ext4_write_inode’:
      > fs/ext4/inode.c:2906: warning: comparison is always true due to limited
      > range of data type
      >
      > fs/jbd2/recovery.c: In function ‘jbd2_journal_recover’:
      > fs/jbd2/recovery.c:254: warning: comparison is always true due to
      > limited range of data type
      > fs/jbd2/recovery.c:257: warning: comparison is always true due to
      > limited range of data type
      >
      > fs/jbd2/recovery.c: In function ‘jbd2_journal_skip_recovery’:
      > fs/jbd2/recovery.c:301: warning: comparison is always true due to
      > limited range of data type
      >
      Noticed all warnings are occurs when the debug level is 0. Then found
      the "jbd2: Move jbd2-debug file to debugfs" patch
      http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0f49d5d019afa4e94253bfc92f0daca3badb990b
      
      
      
      changed the jbd2_journal_enable_debug from int type to u8, makes the
      jbd_debug comparision is always true when the debugging level is 0. Thus
      the compile warning occurs.
      
      Thought about changing the jbd2_journal_enable_debug data type back to
      int, but can't, because the jbd2-debug is moved to debug fs, where
      calling debugfs_create_u8() to create the debugfs entry needs the value
      to be u8 type.
      
      Even if we changed the data type back to int, the code is still buggy,
      kernel should not print jbd2 debug message if the
      jbd2_journal_enable_debug is set to 0. But this is not the case.
      
      The fix is change the level of debugging to 1. The same should fixed in
      ext3/JBD, but currently ext3 jbd-debug via /proc fs is broken, so we
      probably should fix it all together.
      
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: Theodore Tso <tytso@mit.edu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b38bd33a
  10. 18 Jul, 2007 5 commits
  11. 24 Jun, 2007 1 commit
  12. 31 May, 2007 1 commit
  13. 08 May, 2007 2 commits
    • Randy Dunlap's avatar
      header cleaning: don't include smp_lock.h when not used · e63340ae
      Randy Dunlap authored
      
      
      Remove includes of <linux/smp_lock.h> where it is not used/needed.
      Suggested by Al Viro.
      
      Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
      sparc64, and arm (all 59 defconfigs).
      
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e63340ae
    • Markus Rechberger's avatar
      ext2/3/4: fix file date underflow on ext2 3 filesystems on 64 bit systems · 4d7bf11d
      Markus Rechberger authored
      Taken from http://bugzilla.kernel.org/show_bug.cgi?id=5079
      
      
      
      signed long ranges from -2.147.483.648 to 2.147.483.647 on x86 32bit
      
      10000011110110100100111110111101 .. -2,082,844,739
      10000011110110100100111110111101 ..  2,212,122,557 <- this currently gets
      stored on the disk but when converting it to a 64bit signed long value it loses
      its sign and becomes positive.
      
      Cc: Andreas Dilger <adilger@dilger.ca>
      Cc: <linux-ext4@vger.kernel.org>
      
      Andreas says:
      
      This patch is now treating timestamps with the high bit set as negative
      times (before Jan 1, 1970).  This means we lose 1/2 of the possible range
      of timestamps (lopping off 68 years before unix timestamp overflow -
      now only 30 years away :-) to handle the extremely rare case of setting
      timestamps into the distant past.
      
      If we are only interested in fixing the underflow case, we could just
      limit the values to 0 instead of storing negative values.  At worst this
      will skew the timestamp by a few hours for timezones in the far east
      (files would still show Jan 1, 1970 in "ls -l" output).
      
      That said, it seems 32-bit systems (mine at least) allow files to be set
      into the past (01/01/1907 works fine) so it seems this patch is bringing
      the x86_64 behaviour into sync with other kernels.
      
      On the plus side, we have a patch that is ready to add nanosecond timestamps
      to ext3 and as an added bonus adds 2 high bits to the on-disk timestamp so
      this extends the maximum date to 2242.
      
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4d7bf11d
  14. 02 Apr, 2007 1 commit
  15. 11 Feb, 2007 1 commit
  16. 08 Dec, 2006 1 commit
  17. 07 Dec, 2006 1 commit
  18. 11 Oct, 2006 4 commits