1. 10 5月, 2011 8 次提交
  2. 06 4月, 2011 1 次提交
    • J
      fs: export empty_aops · 7dcda1c9
      Jens Axboe 提交于
      With the ->sync_page() hook gone, we have a few users that
      add their own static address_space_operations without any
      functions defined.
      
      fs/inode.c already has an empty_aops that it uses for init
      purposes. Lets export that and use it in the places where
      an otherwise empty aops was defined.
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      7dcda1c9
  3. 30 3月, 2011 3 次提交
    • N
      nilfs2: fix whitespace coding style issues · af71dda0
      Nicolas Kaiser 提交于
      Fixes whitespace coding style issues.
      Signed-off-by: NNicolas Kaiser <nikai@nikai.net>
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      af71dda0
    • R
      nilfs2: fix oops due to a bad aops initialization · d611b22f
      Ryusuke Konishi 提交于
      Nilfs in 2.6.39-rc1 hit the following oops:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
       IP: [<ffffffff810ac235>] try_to_release_page+0x2a/0x3d
       PGD 234cb6067 PUD 234c72067 PMD 0
       Oops: 0000 [#1] SMP
       <snip>
       Process truncate (pid: 10995, threadinfo ffff8802353c2000, task ffff880234cfa000)
       Stack:
        ffff8802333c77b8 ffffffff810b64b0 0000000000003802 ffffffffa0052cca
        0000000000000000 ffff8802353c3b58 0000000000000000 ffff8802353c3b58
        0000000000000001 0000000000000000 ffffea0007b92308 ffffea0007b92308
       Call Trace:
        [<ffffffff810b64b0>] ? invalidate_inode_pages2_range+0x15f/0x273
        [<ffffffffa0052cca>] ? nilfs_palloc_get_block+0x2d/0xaf [nilfs2]
        [<ffffffff810589e7>] ? bit_waitqueue+0x14/0xa1
        [<ffffffff81058ab1>] ? wake_up_bit+0x10/0x20
        [<ffffffffa00433fd>] ? nilfs_forget_buffer+0x66/0x7a [nilfs2]
        [<ffffffffa00467b8>] ? nilfs_btree_concat_left+0x5c/0x77 [nilfs2]
        [<ffffffffa00471fc>] ? nilfs_btree_delete+0x395/0x3cf [nilfs2]
        [<ffffffffa00449a3>] ? nilfs_bmap_do_delete+0x6e/0x79 [nilfs2]
        [<ffffffffa0045845>] ? nilfs_btree_last_key+0x14b/0x15e [nilfs2]
        [<ffffffffa00449dd>] ? nilfs_bmap_truncate+0x2f/0x83 [nilfs2]
        [<ffffffffa0044ab2>] ? nilfs_bmap_last_key+0x35/0x62 [nilfs2]
        [<ffffffffa003e99b>] ? nilfs_truncate_bmap+0x6b/0xc7 [nilfs2]
        [<ffffffffa003ee4a>] ? nilfs_truncate+0x79/0xe4 [nilfs2]
        [<ffffffff810b6c00>] ? vmtruncate+0x33/0x3b
        [<ffffffffa003e8f1>] ? nilfs_setattr+0x4d/0x8c [nilfs2]
        [<ffffffff81026106>] ? do_page_fault+0x31b/0x356
        [<ffffffff810f9d61>] ? notify_change+0x17d/0x262
        [<ffffffff810e5046>] ? do_truncate+0x65/0x80
        [<ffffffff810e52af>] ? sys_ftruncate+0xf1/0xf6
        [<ffffffff8132c012>] ? system_call_fastpath+0x16/0x1b
       Code: c3 48 83 ec 08 48 8b 17 48 8b 47 18 80 e2 01 75 04 0f 0b eb fe 48 8b 17 80 e6 20 74 05 31 c0 41 59 c3 48 85 c0 74 11 48 8b 40 58
        8b 40 48 48 85 c0 74 04 41 58 ff e0 59 e9 b1 b5 05 00 41 54
       RIP  [<ffffffff810ac235>] try_to_release_page+0x2a/0x3d
        RSP <ffff8802353c3b08>
       CR2: 0000000000000048
      
      This oops was brought in by the change "block: remove per-queue
      plugging" (commit: 7eaceacc).  It initializes mapping->a_ops
      with a NULL pointer for some pages in nilfs (e.g. btree node pages),
      but mm code doesn't NULL pointer checks against mapping->a_ops. (the
      check is done for each callback function)
      
      This corrects the aops initialization and fixes the oops.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Acked-by: NJens Axboe <jaxboe@fusionio.com>
      d611b22f
    • R
      nilfs2: fix data loss in mmap page write for hole blocks · 34094537
      Ryusuke Konishi 提交于
      From the result of a function test of mmap, mmap write to shared pages
      turned out to be broken for hole blocks.  It doesn't write out filled
      blocks and the data will be lost after umount.  This is due to a bug
      that the target file is not queued for log writer when filling hole
      blocks.
      
      Also, nilfs_page_mkwrite function exits normal code path even after
      successfully filled hole blocks due to a change of block_page_mkwrite
      function; just after nilfs was merged into the mainline,
      block_page_mkwrite() started to return VM_FAULT_LOCKED instead of zero
      by the patch "mm: close page_mkwrite races" (commit:
      b827e496).  The current nilfs_page_mkwrite() is not handling
      this value properly.
      
      This corrects nilfs_page_mkwrite() and will resolve the data loss
      problem in mmap write.
      
      [This should be applied to every kernel since 2.6.30 but a fix is
       needed for 2.6.37 and prior kernels]
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Tested-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Cc: stable <stable@kernel.org>  [2.6.38]
      34094537
  4. 24 3月, 2011 2 次提交
  5. 10 3月, 2011 2 次提交
    • J
      block: kill off REQ_UNPLUG · 721a9602
      Jens Axboe 提交于
      With the plugging now being explicitly controlled by the
      submitter, callers need not pass down unplugging hints
      to the block layer. If they want to unplug, it's because they
      manually plugged on their own - in which case, they should just
      unplug at will.
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      721a9602
    • J
      block: remove per-queue plugging · 7eaceacc
      Jens Axboe 提交于
      Code has been converted over to the new explicit on-stack plugging,
      and delay users have been converted to use the new API for that.
      So lets kill off the old plugging along with aops->sync_page().
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      7eaceacc
  6. 09 3月, 2011 8 次提交
  7. 08 3月, 2011 10 次提交
  8. 03 3月, 2011 1 次提交
  9. 02 3月, 2011 1 次提交
  10. 24 2月, 2011 1 次提交
    • M
      mm: prevent concurrent unmap_mapping_range() on the same inode · 2aa15890
      Miklos Szeredi 提交于
      Michael Leun reported that running parallel opens on a fuse filesystem
      can trigger a "kernel BUG at mm/truncate.c:475"
      
      Gurudas Pai reported the same bug on NFS.
      
      The reason is, unmap_mapping_range() is not prepared for more than
      one concurrent invocation per inode.  For example:
      
        thread1: going through a big range, stops in the middle of a vma and
           stores the restart address in vm_truncate_count.
      
        thread2: comes in with a small (e.g. single page) unmap request on
           the same vma, somewhere before restart_address, finds that the
           vma was already unmapped up to the restart address and happily
           returns without doing anything.
      
      Another scenario would be two big unmap requests, both having to
      restart the unmapping and each one setting vm_truncate_count to its
      own value.  This could go on forever without any of them being able to
      finish.
      
      Truncate and hole punching already serialize with i_mutex.  Other
      callers of unmap_mapping_range() do not, and it's difficult to get
      i_mutex protection for all callers.  In particular ->d_revalidate(),
      which calls invalidate_inode_pages2_range() in fuse, may be called
      with or without i_mutex.
      
      This patch adds a new mutex to 'struct address_space' to prevent
      running multiple concurrent unmap_mapping_range() on the same mapping.
      
      [ We'll hopefully get rid of all this with the upcoming mm
        preemptibility series by Peter Zijlstra, the "mm: Remove i_mmap_mutex
        lockbreak" patch in particular.  But that is for 2.6.39 ]
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      Reported-by: NMichael Leun <lkml20101129@newton.leun.net>
      Reported-by: NGurudas Pai <gurudas.pai@oracle.com>
      Tested-by: NGurudas Pai <gurudas.pai@oracle.com>
      Acked-by: NHugh Dickins <hughd@google.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2aa15890
  11. 22 1月, 2011 1 次提交
    • R
      nilfs2: fix crash after one superblock became unavailable · 0ca7a5b9
      Ryusuke Konishi 提交于
      Fixes the following kernel oops in nilfs_setup_super() which could
      arise if one of two super-blocks is unavailable.
      
      > BUG: unable to handle kernel NULL pointer dereference at   (null)
      > Pid: 3529, comm: mount.nilfs2 Not tainted 2.6.37 #1 /
      > EIP: 0060:[<c03196bc>] EFLAGS: 00010202 CPU: 3
      > EIP is at memcpy+0xc/0x1b
      > Call Trace:
      >  [<f953720e>] ? nilfs_setup_super+0x6c/0xa5 [nilfs2]
      >  [<f95369e9>] ? nilfs_get_root_dentry+0x81/0xcb [nilfs2]
      >  [<f9537a08>] ? nilfs_mount+0x4f9/0x62c [nilfs2]
      >  [<c02745cf>] ? kstrdup+0x36/0x3f
      >  [<f953750f>] ? nilfs_mount+0x0/0x62c [nilfs2]
      >  [<c0293940>] ? vfs_kern_mount+0x4d/0x12c
      >  [<c02a5100>] ? get_fs_type+0x76/0x8f
      >  [<c0293a68>] ? do_kern_mount+0x33/0xbf
      >  [<c02a784a>] ? do_mount+0x2ed/0x714
      >  [<c02a6171>] ? copy_mount_options+0x28/0xfc
      >  [<c02a7ce3>] ? sys_mount+0x72/0xaf
      >  [<c0473085>] ? syscall_call+0x7/0xb
      Reported-by: NWakko Warner <wakko@animx.eu.org>
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Tested-by: NWakko Warner <wakko@animx.eu.org>
      Cc: stable <stable@kernel.org> [2.6.37, 2.6.36]
      LKML-Reference: <20110121024918.GA29598@animx.eu.org>
      0ca7a5b9
  12. 11 1月, 2011 1 次提交
  13. 10 1月, 2011 1 次提交