1. 05 8月, 2015 1 次提交
    • C
      f2fs: fix to release inode page correctly · 470f00e9
      Chao Yu 提交于
      In following call path, we will pass a locked and referenced ipage
      pointer to get_new_data_page:
       - init_inode_metadata
        - make_empty_dir
         - get_new_data_page
      
      There are two exit paths in get_new_data_page when error occurs:
      1) grab_cache_page fails, ipage will not be released;
      2) f2fs_reserve_block fails, ipage will be released in callee.
      
      So, it's not consistent for error handling in get_new_data_page.
      
      For f2fs_reserve_block, it's not very easy to change the rule
      of error handling, since it's already complicated.
      
      Here we deside to choose an easy way to fix this issue:
      If any error occur in get_new_data_page, we will ensure releasing
      ipage in this function.
      
      The same issue is in f2fs_convert_inline_dir, fix that too.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      470f00e9
  2. 25 7月, 2015 1 次提交
    • J
      f2fs: call set_page_dirty to attach i_wb for cgroup · 6282adbf
      Jaegeuk Kim 提交于
      The cgroup attaches inode->i_wb via mark_inode_dirty and when set_page_writeback
      is called, __inc_wb_stat() updates i_wb's stat.
      
      So, we need to explicitly call set_page_dirty->__mark_inode_dirty in prior to
      any writebacking pages.
      
      This patch should resolve the following kernel panic reported by Andreas Reis.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=101801
      
      --- Comment #2 from Andreas Reis <andreas.reis@gmail.com> ---
      BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
      IP: [<ffffffff8149deea>] __percpu_counter_add+0x1a/0x90
      PGD 2951ff067 PUD 2df43f067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 7 PID: 10356 Comm: gcc Tainted: G        W       4.2.0-1-cu #1
      Hardware name: Gigabyte Technology Co., Ltd. G1.Sniper M5/G1.Sniper M5, BIOS
      T01 02/03/2015
      task: ffff880295044f80 ti: ffff880295140000 task.ti: ffff880295140000
      RIP: 0010:[<ffffffff8149deea>]  [<ffffffff8149deea>]
      __percpu_counter_add+0x1a/0x90
      RSP: 0018:ffff880295143ac8  EFLAGS: 00010082
      RAX: 0000000000000003 RBX: ffffea000a526d40 RCX: 0000000000000001
      RDX: 0000000000000020 RSI: 0000000000000001 RDI: 0000000000000088
      RBP: ffff880295143ae8 R08: 0000000000000000 R09: ffff88008f69bb30
      R10: 00000000fffffffa R11: 0000000000000000 R12: 0000000000000088
      R13: 0000000000000001 R14: ffff88041d099000 R15: ffff880084a205d0
      FS:  00007f8549374700(0000) GS:ffff88042f3c0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000000a8 CR3: 000000033e1d5000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Stack:
       0000000000000000 ffffea000a526d40 ffff880084a20738 ffff880084a20750
       ffff880295143b48 ffffffff811cc91e ffff880000000000 0000000000000296
       0000000000000000 ffff880417090198 0000000000000000 ffffea000a526d40
      Call Trace:
       [<ffffffff811cc91e>] __test_set_page_writeback+0xde/0x1d0
       [<ffffffff813fee87>] do_write_data_page+0xe7/0x3a0
       [<ffffffff813faeea>] gc_data_segment+0x5aa/0x640
       [<ffffffff813fb0b8>] do_garbage_collect+0x138/0x150
       [<ffffffff813fb3fe>] f2fs_gc+0x1be/0x3e0
       [<ffffffff81405541>] f2fs_balance_fs+0x81/0x90
       [<ffffffff813ee357>] f2fs_unlink+0x47/0x1d0
       [<ffffffff81239329>] vfs_unlink+0x109/0x1b0
       [<ffffffff8123e3d7>] do_unlinkat+0x287/0x2c0
       [<ffffffff8123ebc6>] SyS_unlink+0x16/0x20
       [<ffffffff81942e2e>] entry_SYSCALL_64_fastpath+0x12/0x71
      Code: 41 5e 5d c3 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 55 49
      89 f5 41 54 49 89 fc 53 48 83 ec 08 65 ff 05 e6 d9 b6 7e <48> 8b 47 20 48 63 ca
      65 8b 18 48 63 db 48 01 f3 48 39 cb 7d 0a
      RIP  [<ffffffff8149deea>] __percpu_counter_add+0x1a/0x90
       RSP <ffff880295143ac8>
      CR2: 00000000000000a8
      ---[ end trace 5132449a58ed93a3 ]---
      note: gcc[10356] exited with preempt_count 2
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      6282adbf
  3. 29 5月, 2015 6 次提交
  4. 11 4月, 2015 5 次提交
    • J
      f2fs: add F2FS_INLINE_DOTS to recover missing dot dentries · 510022a8
      Jaegeuk Kim 提交于
      If f2fs was corrupted with missing dot dentries, it needs to recover them after
      fsck.f2fs detection.
      
      The underlying precedure is:
      
      1. The fsck.f2fs remains F2FS_INLINE_DOTS flag in directory inode, if it detects
      missing dot dentries.
      
      2. When f2fs looks up the corrupted directory, it triggers f2fs_add_link with
      proper inode numbers and their dot and dotdot names.
      
      3. Once f2fs recovers the directory without errors, it removes F2FS_INLINE_DOTS
      finally.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      510022a8
    • C
      f2fs: split set_data_blkaddr from f2fs_update_extent_cache · 216a620a
      Chao Yu 提交于
      Split __set_data_blkaddr from f2fs_update_extent_cache for readability.
      
      Additionally rename __set_data_blkaddr to set_data_blkaddr for exporting.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      216a620a
    • W
      f2fs: enable fast symlink by utilizing inline data · 368a0e40
      Wanpeng Li 提交于
      Fast symlink can utilize inline data flow to avoid using any
      i_addr region, since we need to handle many cases such as
      truncation, roll-forward recovery, and fsck/dump tools.
      Signed-off-by: NWanpeng Li <wanpeng.li@linux.intel.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      368a0e40
    • J
      f2fs: avoid wrong f2fs_bug_on when truncating inline_data · 83e21db6
      Jaegeuk Kim 提交于
      This patch removes wrong f2fs_bug_on in truncate_inline_inode.
      
      When there is no space, it can happen a corner case where i_isze is over
      MAX_INLINE_SIZE while its inode is still inline_data.
      
      The scenario is
       1. write small data into file #A.
       2. fill the whole partition to 100%.
       3. truncate 4096 on file #A.
       4. write data at 8192 offset.
        --> f2fs_write_begin
          -> -ENOSPC = f2fs_convert_inline_page
          -> f2fs_write_failed
            -> truncate_blocks
              -> truncate_inline_inode
      	  BUG_ON, since i_size is 4096.
      Reviewed-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      83e21db6
    • C
      f2fs: fix to truncate inline data past EOF · 0bfcfcca
      Chao Yu 提交于
      Previously if inode is with inline data, we will try to invalid partial inline
      data in page #0 when we truncate size of inode in truncate_partial_data_page().
      And then we set page #0 to dirty, after this we can synchronize inode page with
      page #0 at ->writepage().
      
      But sometimes we will fail to operate page #0 in truncate_partial_data_page()
      due to below reason:
      a) if offset is zero, we will skip setting page #0 to dirty.
      b) if page #0 is not uptodate, we will fail to update it as it has no mapping
      data.
      
      So with following operations, we will meet recent data which should be
      truncated.
      
      1.write inline data to file
      2.sync first data page to inode page
      3.truncate file size to 0
      4.truncate file size to max_inline_size
      5.echo 1 > /proc/sys/vm/drop_caches
      6.read file --> meet original inline data which is remained in inode page.
      
      This patch renames truncate_inline_data() to truncate_inline_inode() for code
      readability, then use truncate_inline_inode() to truncate inline data in inode
      page in truncate_blocks() and truncate page #0 in truncate_partial_data_page()
      for fixing.
      
      v2:
       o truncate partially #0 page in truncate_partial_data_page to avoid keeping
         old data in #0 page.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      0bfcfcca
  5. 04 3月, 2015 2 次提交
  6. 12 2月, 2015 1 次提交
  7. 10 1月, 2015 2 次提交
  8. 26 11月, 2014 2 次提交
  9. 24 11月, 2014 1 次提交
  10. 19 11月, 2014 1 次提交
  11. 12 11月, 2014 1 次提交
    • 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
  12. 11 11月, 2014 1 次提交
  13. 05 11月, 2014 1 次提交
    • J
      f2fs: revisit inline_data to avoid data races and potential bugs · b3d208f9
      Jaegeuk Kim 提交于
      This patch simplifies the inline_data usage with the following rule.
      1. inline_data is set during the file creation.
      2. If new data is requested to be written ranges out of inline_data,
       f2fs converts that inode permanently.
      3. There is no cases which converts non-inline_data inode to inline_data.
      4. The inline_data flag should be changed under inode page lock.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      b3d208f9
  14. 04 11月, 2014 14 次提交
  15. 07 10月, 2014 1 次提交
    • J
      f2fs: support atomic writes · 88b88a66
      Jaegeuk Kim 提交于
      This patch introduces a very limited functionality for atomic write support.
      In order to support atomic write, this patch adds two ioctls:
       o F2FS_IOC_START_ATOMIC_WRITE
       o F2FS_IOC_COMMIT_ATOMIC_WRITE
      
      The database engine should be aware of the following sequence.
      1. open
       -> ioctl(F2FS_IOC_START_ATOMIC_WRITE);
      2. writes
        : all the written data will be treated as atomic pages.
      3. commit
       -> ioctl(F2FS_IOC_COMMIT_ATOMIC_WRITE);
        : this flushes all the data blocks to the disk, which will be shown all or
        nothing by f2fs recovery procedure.
      4. repeat to #2.
      
      The IO pattens should be:
      
        ,- START_ATOMIC_WRITE                  ,- COMMIT_ATOMIC_WRITE
       CP | D D D D D D | FSYNC | D D D D | FSYNC ...
                            `- COMMIT_ATOMIC_WRITE
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      88b88a66