1. 08 2月, 2008 1 次提交
  2. 07 2月, 2008 1 次提交
  3. 06 2月, 2008 1 次提交
    • C
      Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user · eebd2aa3
      Christoph Lameter 提交于
      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: NChristoph 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eebd2aa3
  4. 29 1月, 2008 13 次提交
  5. 18 10月, 2007 3 次提交
  6. 17 10月, 2007 1 次提交
  7. 20 7月, 2007 1 次提交
    • M
      fix ext4/JBD2 build warnings · b38bd33a
      Mingming Cao 提交于
      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: NMingming Cao <cmm@us.ibm.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: Theodore Tso <tytso@mit.edu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b38bd33a
  8. 18 7月, 2007 5 次提交
  9. 24 6月, 2007 1 次提交
  10. 01 6月, 2007 1 次提交
  11. 09 5月, 2007 2 次提交
    • R
      header cleaning: don't include smp_lock.h when not used · e63340ae
      Randy Dunlap 提交于
      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: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e63340ae
    • M
      ext2/3/4: fix file date underflow on ext2 3 filesystems on 64 bit systems · 4d7bf11d
      Markus Rechberger 提交于
      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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4d7bf11d
  12. 03 4月, 2007 1 次提交
  13. 12 2月, 2007 1 次提交
  14. 09 12月, 2006 1 次提交
  15. 08 12月, 2006 1 次提交
  16. 12 10月, 2006 6 次提交