1. 30 3月, 2011 2 次提交
    • 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
  2. 29 3月, 2011 3 次提交
  3. 28 3月, 2011 34 次提交
  4. 27 3月, 2011 1 次提交