1. 02 8月, 2014 1 次提交
  2. 31 7月, 2014 9 次提交
  3. 29 7月, 2014 5 次提交
  4. 25 7月, 2014 4 次提交
    • C
      f2fs: fix to put root inode in error path of fill_super · 9d847950
      Chao Yu 提交于
      We should put root inode correctly in error path of fill_super, otherwise we
      may encounter a leak case of inode resource.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Reviewed-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      9d847950
    • C
      f2fs: avoid use invalid mapping of node_inode when evict meta inode · dbf20cb2
      Chao Yu 提交于
      Andrey Tsyvarev reported:
      "Using memory error detector reveals the following use-after-free error
      in 3.15.0:
      
      AddressSanitizer: heap-use-after-free in f2fs_evict_inode
      Read of size 8 by thread T22279:
        [<ffffffffa02d8702>] f2fs_evict_inode+0x102/0x2e0 [f2fs]
        [<ffffffff812359af>] evict+0x15f/0x290
        [<     inlined    >] iput+0x196/0x280 iput_final
        [<ffffffff812369a6>] iput+0x196/0x280
        [<ffffffffa02dc416>] f2fs_put_super+0xd6/0x170 [f2fs]
        [<ffffffff81210095>] generic_shutdown_super+0xc5/0x1b0
        [<ffffffff812105fd>] kill_block_super+0x4d/0xb0
        [<ffffffff81210a86>] deactivate_locked_super+0x66/0x80
        [<ffffffff81211c98>] deactivate_super+0x68/0x80
        [<ffffffff8123cc88>] mntput_no_expire+0x198/0x250
        [<     inlined    >] SyS_umount+0xe9/0x1a0 SYSC_umount
        [<ffffffff8123f1c9>] SyS_umount+0xe9/0x1a0
        [<ffffffff81cc8df9>] system_call_fastpath+0x16/0x1b
      
      Freed by thread T3:
        [<ffffffffa02dc337>] f2fs_i_callback+0x27/0x30 [f2fs]
        [<     inlined    >] rcu_process_callbacks+0x2d6/0x930 __rcu_reclaim
        [<     inlined    >] rcu_process_callbacks+0x2d6/0x930 rcu_do_batch
        [<     inlined    >] rcu_process_callbacks+0x2d6/0x930 invoke_rcu_callbacks
        [<     inlined    >] rcu_process_callbacks+0x2d6/0x930 __rcu_process_callbacks
        [<ffffffff810fd266>] rcu_process_callbacks+0x2d6/0x930
        [<ffffffff8107cce2>] __do_softirq+0x142/0x380
        [<ffffffff8107cf50>] run_ksoftirqd+0x30/0x50
        [<ffffffff810b2a87>] smpboot_thread_fn+0x197/0x280
        [<ffffffff810a8238>] kthread+0x148/0x160
        [<ffffffff81cc8d4c>] ret_from_fork+0x7c/0xb0
      
      Allocated by thread T22276:
        [<ffffffffa02dc7dd>] f2fs_alloc_inode+0x2d/0x170 [f2fs]
        [<ffffffff81235e2a>] iget_locked+0x10a/0x230
        [<ffffffffa02d7495>] f2fs_iget+0x35/0xa80 [f2fs]
        [<ffffffffa02e2393>] f2fs_fill_super+0xb53/0xff0 [f2fs]
        [<ffffffff81211bce>] mount_bdev+0x1de/0x240
        [<ffffffffa02dbce0>] f2fs_mount+0x10/0x20 [f2fs]
        [<ffffffff81212a85>] mount_fs+0x55/0x220
        [<ffffffff8123c026>] vfs_kern_mount+0x66/0x200
        [<     inlined    >] do_mount+0x2b4/0x1120 do_new_mount
        [<ffffffff812400d4>] do_mount+0x2b4/0x1120
        [<     inlined    >] SyS_mount+0xb2/0x110 SYSC_mount
        [<ffffffff812414a2>] SyS_mount+0xb2/0x110
        [<ffffffff81cc8df9>] system_call_fastpath+0x16/0x1b
      
      The buggy address ffff8800587866c8 is located 48 bytes inside
        of 680-byte region [ffff880058786698, ffff880058786940)
      
      Memory state around the buggy address:
        ffff880058786100: ffffffff ffffffff ffffffff ffffffff
        ffff880058786200: ffffffff ffffffff ffffffrr rrrrrrrr
        ffff880058786300: rrrrrrrr rrffffff ffffffff ffffffff
        ffff880058786400: ffffffff ffffffff ffffffff ffffffff
        ffff880058786500: ffffffff ffffffff ffffffff fffffffr
       >ffff880058786600: rrrrrrrr rrrrrrrr rrrfffff ffffffff
                                                      ^
        ffff880058786700: ffffffff ffffffff ffffffff ffffffff
        ffff880058786800: ffffffff ffffffff ffffffff ffffffff
        ffff880058786900: ffffffff rrrrrrrr rrrrrrrr rrrr....
        ffff880058786a00: ........ ........ ........ ........
        ffff880058786b00: ........ ........ ........ ........
      Legend:
        f - 8 freed bytes
        r - 8 redzone bytes
        . - 8 allocated bytes
        x=1..7 - x allocated bytes + (8-x) redzone bytes
      
      Investigation shows, that f2fs_evict_inode, when called for
      'meta_inode', uses invalidate_mapping_pages() for 'node_inode'.
      But 'node_inode' is deleted before 'meta_inode' in f2fs_put_super via
      iput().
      
      It seems that in common usage scenario this use-after-free is benign,
      because 'node_inode' remains partially valid data even after
      kmem_cache_free().
      But things may change if, while 'meta_inode' is evicted in one f2fs
      filesystem, another (mounted) f2fs filesystem requests inode from cache,
      and formely
      'node_inode' of the first filesystem is returned."
      
      Nids for both meta_inode and node_inode are reservation, so it's not necessary
      for us to invalidate pages which will never be allocated.
      To fix this issue, let's skipping needlessly invalidating pages for
      {meta,node}_inode in f2fs_evict_inode.
      Reported-by: NAndrey Tsyvarev <tsyvarev@ispras.ru>
      Tested-by: NAndrey Tsyvarev <tsyvarev@ispras.ru>
      Signed-off-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      dbf20cb2
    • C
      f2fs: support ->rename2() · 32f9bc25
      Chao Yu 提交于
      Now new interface ->rename2() is added to VFS, here are related description:
      https://lkml.org/lkml/2014/2/7/873
      https://lkml.org/lkml/2014/2/7/758
      
      This patch adds function f2fs_rename2() to support ->rename2() including
      handling both RENAME_EXCHANGE and RENAME_NOREPLACE flag.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      32f9bc25
    • H
      f2fs: add f2fs_balance_fs for direct IO · 79e35dc3
      Huang Ying 提交于
      Otherwise, if a large amount of direct IO writes were done, the
      segment allocation may be failed because no enough segments are gced.
      
      Changes:
      
      v2: add f2fs_balance_fs into __get_data_block instead of f2fs_direct_IO.
      Signed-off-by: NHuang, Ying <ying.huang@intel.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      79e35dc3
  5. 16 7月, 2014 1 次提交
  6. 12 7月, 2014 2 次提交
  7. 11 7月, 2014 1 次提交
    • C
      f2fs: check name_len of dir entry to prevent from deadloop · 81e366f8
      Chao Yu 提交于
      We assume that modification of some special application could result in zeroed
      name_len, or it is consciously made by somebody. We will deadloop in
      find_in_block when name_len of dir entry is zero.
      
      This patch is added for preventing deadloop in above scenario.
      
      change log from v1:
       o use f2fs_bug_on rather than break out from searching dir entry suggested by
      Jaegeuk Kim.
      
      Jaegeuk describe:
      "Well, IMO, it would be good to add f2fs_bug_on() here with a specific comment.
      In the current phase of f2fs, it is more important to investigate the file
      system bugs, rather than workarounds for any corrupted images.
      And, definitely it needs to stop the kernel if any corrupted image was mounted,
      so that we can figure out where the bugs are occurred."
      Suggested-by: NJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      81e366f8
  8. 10 7月, 2014 14 次提交
  9. 09 7月, 2014 3 次提交
    • C
      f2fs: avoid to access NULL pointer in issue_flush_thread · 50e1f8d2
      Chao Yu 提交于
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75861
      
      Denis 2014-05-10 11:28:59 UTC reported:
      "F2FS-fs (mmcblk0p28): mounting..
       Unable to handle kernel NULL pointer dereference at virtual address 00000018
       ...
       [<c0a2f678>] (_raw_spin_lock+0x3c/0x70) from [<c03a0330>] (issue_flush_thread+0x50/0x17c)
       [<c03a0330>] (issue_flush_thread+0x50/0x17c) from [<c01b4064>] (kthread+0x98/0xa4)
       [<c01b4064>] (kthread+0x98/0xa4) from [<c0108060>] (kernel_thread_exit+0x0/0x8)"
      
      This patch assign cmd_control_info in sm_info before issue_flush_thread is being
      created, so this make sure that issue flush thread will have no chance to access
      invalid info in fcc.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Reviewed-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      50e1f8d2
    • J
      f2fs: check bdi->dirty_exceeded when trying to skip data writes · 2743f865
      Jaegeuk Kim 提交于
      If we don't check the current backing device status, balance_dirty_pages can
      fall into infinite pausing routine.
      
      This can be occurred when a lot of directories make a small number of dirty
      dentry pages including files.
      Reported-by: NBrian Chadwick <brianchad@westnet.com.au>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      2743f865
    • J
      f2fs: do checkpoint for the renamed inode · b2c08299
      Jaegeuk Kim 提交于
      If an inode is renamed, it should be registered as file_lost_pino to conduct
      checkpoint at f2fs_sync_file.
      Otherwise, the inode cannot be recovered due to no dent_mark in the following
      scenario.
      
      Note that, this scenario is from xfstests/322.
      
      1. create "a"
      2. fsync "a"
      3. rename "a" to "b"
      4. fsync "b"
      5. Sudden power-cut
      
      After recovery is done, "b" should be seen.
      However, the result shows "a", since the recovery procedure does not enter
      recover_dentry due to no dent_mark.
      
      The reason is like below.
      - The nid of "a" is checkpointed during #2, f2fs_sync_file.
      - The inode page for "b" produced by #3 is written without dent_mark by
      sync_node_pages.
      
      So, this patch fixes this bug by assinging file_lost_pino to the "a"'s inode.
      If the pino is lost, f2fs_sync_file conducts checkpoint, and then recovers
      the latest pino and its dentry information for further recovery.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      b2c08299