1. 29 10月, 2006 6 次提交
    • H
      [PATCH] hugetlb: fix size=4G parsing · b9d7e6ae
      Hugh Dickins 提交于
      On 32-bit machines, mount -t hugetlbfs -o size=4G gave a 0GB filesystem,
      size=5G gave a 1GB filesystem etc: there's no point in masking size with
      HPAGE_MASK just before shifting its lower bits away, and since HPAGE_MASK is a
      UL, that removed all the higher bits of the unsigned long long size.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Cc: Adam Litke <agl@us.ibm.com>
      Cc: David Gibson <david@gibson.dropbear.id.au>
      Cc: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b9d7e6ae
    • P
      [PATCH] Fix potential OOPs in blkdev_open() · 6a2aae06
      Pavel Emelianov 提交于
      blkdev_open() calls bc_acquire() to get a struct block_device.  Since
      bc_acquire() may return NULL when system is out of memory an appropriate
      check is required.
      Signed-off-by: NPavel Emelianov <xemul@openvz.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6a2aae06
    • E
      [PATCH] jbd2: journal_dirty_data re-check for unmapped buffers · 9b57988d
      Eric Sandeen 提交于
      When running several fsx's and other filesystem stress tests, we found
      cases where an unmapped buffer was still being sent to submit_bh by the
      ext3 dirty data journaling code.
      
      I saw this happen in two ways, both related to another thread doing a
      truncate which would unmap the buffer in question.
      
      Either we would get into journal_dirty_data with a bh which was already
      unmapped (although journal_dirty_data_fn had checked for this earlier, the
      state was not locked at that point), or it would get unmapped in the middle
      of journal_dirty_data when we dropped locks to call sync_dirty_buffer.
      
      By re-checking for mapped state after we've acquired the bh state lock, we
      should avoid these races.  If we find a buffer which is no longer mapped,
      we essentially ignore it, because journal_unmap_buffer has already decided
      that this buffer can go away.
      
      I've also added tracepoints in these two cases, and made a couple other
      tracepoint changes that I found useful in debugging this.
      Signed-off-by: NEric Sandeen <esandeen@redhat.com>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9b57988d
    • E
      [PATCH] jbd: journal_dirty_data re-check for unmapped buffers · f58a74dc
      Eric Sandeen 提交于
      When running several fsx's and other filesystem stress tests, we found
      cases where an unmapped buffer was still being sent to submit_bh by the
      ext3 dirty data journaling code.
      
      I saw this happen in two ways, both related to another thread doing a
      truncate which would unmap the buffer in question.
      
      Either we would get into journal_dirty_data with a bh which was already
      unmapped (although journal_dirty_data_fn had checked for this earlier, the
      state was not locked at that point), or it would get unmapped in the middle
      of journal_dirty_data when we dropped locks to call sync_dirty_buffer.
      
      By re-checking for mapped state after we've acquired the bh state lock, we
      should avoid these races.  If we find a buffer which is no longer mapped,
      we essentially ignore it, because journal_unmap_buffer has already decided
      that this buffer can go away.
      
      I've also added tracepoints in these two cases, and made a couple other
      tracepoint changes that I found useful in debugging this.
      Signed-off-by: NEric Sandeen <esandeen@redhat.com>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f58a74dc
    • R
      [PATCH] ext4: fix printk format warnings · 1939e49a
      Randy Dunlap 提交于
      fs/ext4/resize.c:72: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:76: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:81: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:85: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:89: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:89: warning: long long unsigned int format, __u64 arg (arg 5)
      fs/ext4/resize.c:93: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:93: warning: long long unsigned int format, __u64 arg (arg 5)
      fs/ext4/resize.c:98: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:103: warning: long long unsigned int format, __u64 arg (arg 4)
      fs/ext4/resize.c:109: warning: long long unsigned int format, __u64 arg (arg 4)
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1939e49a
    • N
      [PATCH] mm: clean up pagecache allocation · 2ae88149
      Nick Piggin 提交于
      - Consolidate page_cache_alloc
      
      - Fix splice: only the pagecache pages and filesystem data need to use
        mapping_gfp_mask.
      
      - Fix grab_cache_page_nowait: same as splice, also honour NUMA placement.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2ae88149
  2. 25 10月, 2006 1 次提交
  3. 22 10月, 2006 2 次提交
  4. 21 10月, 2006 31 次提交