1. 09 12月, 2014 4 次提交
  2. 06 12月, 2014 1 次提交
    • J
      f2fs: call radix_tree_preload before radix_tree_insert · 769ec6e5
      Jaegeuk Kim 提交于
      This patch tries to fix:
      
       BUG: using smp_processor_id() in preemptible [00000000] code: f2fs_gc-254:0/384
        (radix_tree_node_alloc+0x14/0x74) from [<c033d8a0>] (radix_tree_insert+0x110/0x200)
        (radix_tree_insert+0x110/0x200) from [<c02e8264>] (gc_data_segment+0x340/0x52c)
        (gc_data_segment+0x340/0x52c) from [<c02e8658>] (f2fs_gc+0x208/0x400)
        (f2fs_gc+0x208/0x400) from [<c02e8a98>] (gc_thread_func+0x248/0x28c)
        (gc_thread_func+0x248/0x28c) from [<c0139944>] (kthread+0xa0/0xac)
        (kthread+0xa0/0xac) from [<c0105ef8>] (ret_from_fork+0x14/0x3c)
      
      The reason is that f2fs calls radix_tree_insert under enabled preemption.
      So, before calling it, we need to call radix_tree_preload.
      
      Otherwise, we should use _GFP_WAIT for the radix tree, and use mutex or
      semaphore to cover the radix tree operations.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      769ec6e5
  3. 04 12月, 2014 2 次提交
  4. 03 12月, 2014 1 次提交
  5. 02 12月, 2014 2 次提交
  6. 28 11月, 2014 1 次提交
  7. 26 11月, 2014 6 次提交
  8. 24 11月, 2014 4 次提交
  9. 20 11月, 2014 5 次提交
  10. 19 11月, 2014 2 次提交
  11. 12 11月, 2014 2 次提交
    • J
      f2fs: convert inline_data when i_size becomes large · 92dffd01
      Jaegeuk Kim 提交于
      If i_size becomes large outside of MAX_INLINE_DATA, we shoud convert the inode.
      Otherwise, we can make some dirty pages during the truncation, and those pages
      will be written through f2fs_write_data_page.
      At that moment, the inode has still inline_data, so that it tries to write non-
      zero pages into inline_data area.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      92dffd01
    • J
      f2fs: fix deadlock to grab 0'th data page · 764d2c80
      Jaegeuk Kim 提交于
      The scenario is like this.
      
      One trhead triggers:
        f2fs_write_data_pages
          lock_page
          f2fs_write_data_page
            f2fs_lock_op  <- wait
      
      The other thread triggers:
        f2fs_truncate
          truncate_blocks
            f2fs_lock_op
              truncate_partial_data_page
                lock_page  <- wait for locking the page
      
      This patch resolves this bug by relocating truncate_partial_data_page.
      This function is just to truncate user data page and not related to FS
      consistency as well.
      And, we don't need to call truncate_inline_data. Rather than that,
      f2fs_write_data_page will finally update inline_data later.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      764d2c80
  12. 11 11月, 2014 1 次提交
  13. 10 11月, 2014 3 次提交
  14. 07 11月, 2014 2 次提交
  15. 06 11月, 2014 1 次提交
  16. 05 11月, 2014 3 次提交