1. 09 1月, 2016 1 次提交
  2. 07 1月, 2016 1 次提交
  3. 04 1月, 2016 1 次提交
  4. 01 1月, 2016 1 次提交
    • J
      f2fs: write pending bios when cp_error is set · 8d4ea29b
      Jaegeuk Kim 提交于
      When testing ioc_shutdown, put_super is able to be hanged by waiting for
      writebacking pages as follows.
      
      INFO: task umount:2723 blocked for more than 120 seconds.
            Tainted: G           O    4.4.0-rc3+ #8
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      umount          D ffff88000859f9d8     0  2723   2110 0x00000000
       ffff88000859f9d8 0000000000000000 0000000000000000 ffffffff81e11540
       ffff880078c225c0 ffff8800085a0000 ffff88007fc17440 7fffffffffffffff
       ffffffff818239f0 ffff88000859fb48 ffff88000859f9f0 ffffffff8182310c
      Call Trace:
       [<ffffffff818239f0>] ? bit_wait+0x50/0x50
       [<ffffffff8182310c>] schedule+0x3c/0x90
       [<ffffffff81827fb9>] schedule_timeout+0x2d9/0x430
       [<ffffffff810e0f8f>] ? mark_held_locks+0x6f/0xa0
       [<ffffffff8111614d>] ? ktime_get+0x7d/0x140
       [<ffffffff818239f0>] ? bit_wait+0x50/0x50
       [<ffffffff8106a655>] ? kvm_clock_get_cycles+0x25/0x30
       [<ffffffff8111617c>] ? ktime_get+0xac/0x140
       [<ffffffff818239f0>] ? bit_wait+0x50/0x50
       [<ffffffff81822564>] io_schedule_timeout+0xa4/0x110
       [<ffffffff81823a25>] bit_wait_io+0x35/0x50
       [<ffffffff818235bd>] __wait_on_bit+0x5d/0x90
       [<ffffffff811b9e8b>] wait_on_page_bit+0xcb/0xf0
       [<ffffffff810d5f90>] ? autoremove_wake_function+0x40/0x40
       [<ffffffff811cf84c>] truncate_inode_pages_range+0x4bc/0x840
       [<ffffffff811cfc3d>] truncate_inode_pages_final+0x4d/0x60
       [<ffffffffc023ced5>] f2fs_evict_inode+0x75/0x400 [f2fs]
       [<ffffffff812639bc>] evict+0xbc/0x190
       [<ffffffff81263d19>] iput+0x229/0x2c0
       [<ffffffffc0241885>] f2fs_put_super+0x105/0x1a0 [f2fs]
       [<ffffffff8124756a>] generic_shutdown_super+0x6a/0xf0
       [<ffffffff812478f7>] kill_block_super+0x27/0x70
       [<ffffffffc0241290>] kill_f2fs_super+0x20/0x30 [f2fs]
       [<ffffffff81247b03>] deactivate_locked_super+0x43/0x70
       [<ffffffff81247f4c>] deactivate_super+0x5c/0x60
       [<ffffffff81268d2f>] cleanup_mnt+0x3f/0x90
       [<ffffffff81268dc2>] __cleanup_mnt+0x12/0x20
       [<ffffffff810ac463>] task_work_run+0x73/0xa0
       [<ffffffff810032ac>] exit_to_usermode_loop+0xcc/0xd0
       [<ffffffff81003e7c>] syscall_return_slowpath+0xcc/0xe0
       [<ffffffff81829ea2>] int_ret_from_sys_call+0x25/0x9f
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      8d4ea29b
  5. 31 12月, 2015 10 次提交
  6. 18 12月, 2015 1 次提交
  7. 17 12月, 2015 1 次提交
  8. 05 12月, 2015 4 次提交
  9. 21 10月, 2015 2 次提交
  10. 14 10月, 2015 1 次提交
    • C
      f2fs crypto: fix racing of accessing encrypted page among · 08b39fbd
      Chao Yu 提交于
       different competitors
      
      Since we use different page cache (normally inode's page cache for R/W
      and meta inode's page cache for GC) to cache the same physical block
      which is belong to an encrypted inode. Writeback of these two page
      cache should be exclusive, but now we didn't handle writeback state
      well, so there may be potential racing problem:
      
      a)
      kworker:				f2fs_gc:
       - f2fs_write_data_pages
        - f2fs_write_data_page
         - do_write_data_page
          - write_data_page
           - f2fs_submit_page_mbio
      (page#1 in inode's page cache was queued
      in f2fs bio cache, and be ready to write
      to new blkaddr)
      					 - gc_data_segment
      					  - move_encrypted_block
      					   - pagecache_get_page
      					(page#2 in meta inode's page cache
      					was cached with the invalid datas
      					of physical block located in new
      					blkaddr)
      					   - f2fs_submit_page_mbio
      					(page#1 was submitted, later, page#2
      					with invalid data will be submitted)
      
      b)
      f2fs_gc:
       - gc_data_segment
        - move_encrypted_block
         - f2fs_submit_page_mbio
      (page#1 in meta inode's page cache was
      queued in f2fs bio cache, and be ready
      to write to new blkaddr)
      					user thread:
      					 - f2fs_write_begin
      					  - f2fs_submit_page_bio
      					(we submit the request to block layer
      					to update page#2 in inode's page cache
      					with physical block located in new
      					blkaddr, so here we may read gabbage
      					data from new blkaddr since GC hasn't
      					writebacked the page#1 yet)
      
      This patch fixes above potential racing problem for encrypted inode.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      08b39fbd
  11. 13 10月, 2015 3 次提交
  12. 10 10月, 2015 5 次提交
    • J
      f2fs: do not skip dentry block writes · 90b803e6
      Jaegeuk Kim 提交于
      Previously, we skip dentry block writes when wbc is SYNC_NONE with no memory
      pressure and the number of dirty pages is pretty small.
      
      But, we didn't skip for normal data writes, which gives us not much big impact
      on overall performance.
      Moreover, by skipping some data writes, kworker falls into infinite loop to try
      to write blocks, when many dir inodes have only one dentry block.
      
      So, this patch removes skipping data writes.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      90b803e6
    • C
      f2fs: use correct flag in f2fs_map_blocks() · 46c9e141
      Chao Yu 提交于
      We introduce F2FS_GET_BLOCK_READ in commit e2b4e2bc ("f2fs: fix
      incorrect mapping for bmap"), but forget to use this flag in the right
      place, fix it.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      46c9e141
    • C
      f2fs: fix to handle io error in ->direct_IO · f9811703
      Chao Yu 提交于
      Here is a oops reported as following message when testing generic/019 of
      xfstest:
      
       ------------[ cut here ]------------
       kernel BUG at /home/yuchao/git/f2fs-dev/segment.c:882!
       invalid opcode: 0000 [#1] SMP
       Modules linked in: zram lz4_compress lz4_decompress f2fs(O) ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4
      nf_def
       CPU: 2 PID: 25441 Comm: fio Tainted: G           O    4.3.0-rc1+ #6
       Hardware name: Hewlett-Packard HP Z220 CMT Workstation/1790, BIOS K51 v01.61 05/16/2013
       task: ffff8803f4e85580 ti: ffff8803fd61c000 task.ti: ffff8803fd61c000
       RIP: 0010:[<ffffffffa0784981>]  [<ffffffffa0784981>] new_curseg+0x321/0x330 [f2fs]
       RSP: 0018:ffff8803fd61f918  EFLAGS: 00010246
       RAX: 00000000000007ed RBX: 0000000000000224 RCX: 000000000000001f
       RDX: 0000000000000800 RSI: ffffffffffffffff RDI: ffff8803f56f4300
       RBP: ffff8803fd61f978 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000024 R11: ffff8800d23bbd78 R12: ffff8800d0ef0000
       R13: 0000000000000224 R14: 0000000000000000 R15: 0000000000000001
       FS:  00007f827ff85700(0000) GS:ffff88041ea80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: ffffffffff600000 CR3: 00000003fef17000 CR4: 00000000001406e0
       Stack:
        000007ea00000002 0000000100000001 ffff8803f6456248 000007ed0000002b
        0000000000000224 ffff880404d1aa20 ffff8803fd61f9c8 ffff8800d0ef0000
        ffff8803f6456248 0000000000000001 00000000ffffffff ffffffffa078f358
       Call Trace:
        [<ffffffffa0785b87>] allocate_segment_by_default+0x1a7/0x1f0 [f2fs]
        [<ffffffffa078322c>] allocate_data_block+0x17c/0x360 [f2fs]
        [<ffffffffa0779521>] __allocate_data_block+0x131/0x1d0 [f2fs]
        [<ffffffffa077a995>] f2fs_direct_IO+0x4b5/0x580 [f2fs]
        [<ffffffff811510ae>] generic_file_direct_write+0xae/0x160
        [<ffffffff811518f5>] __generic_file_write_iter+0xd5/0x1f0
        [<ffffffff81151e07>] generic_file_write_iter+0xf7/0x200
        [<ffffffff81319e38>] ? apparmor_file_permission+0x18/0x20
        [<ffffffffa0768480>] ? f2fs_fallocate+0x1190/0x1190 [f2fs]
        [<ffffffffa07684c6>] f2fs_file_write_iter+0x46/0x90 [f2fs]
        [<ffffffff8120b4fe>] aio_run_iocb+0x1ee/0x290
        [<ffffffff81700f7e>] ? mutex_lock+0x1e/0x50
        [<ffffffff8120a1d7>] ? aio_read_events+0x207/0x2b0
        [<ffffffff8120b913>] do_io_submit+0x373/0x630
        [<ffffffff8120a4f6>] ? SyS_io_getevents+0x56/0xb0
        [<ffffffff8120bbe0>] SyS_io_submit+0x10/0x20
        [<ffffffff81703857>] entry_SYSCALL_64_fastpath+0x12/0x6a
       Code: 45 c8 48 8b 78 10 e8 9f 23 bf e0 41 8b 8c 24 cc 03 00 00 89 c7 31 d2 89 c6 89 d8 29 df f7 f1 29 d1 39 cf 0f 83 be fd ff ff eb
       RIP  [<ffffffffa0784981>] new_curseg+0x321/0x330 [f2fs]
        RSP <ffff8803fd61f918>
       ---[ end trace 2e577d7f711ddb86 ]---
      
      The reason is that: in the test of generic/019, we will trigger a manmade
      IO error in block layer through debugfs, after that, prefree segment will
      no longer be freed, because we always skip doing gc or checkpoint when
      there occurs an IO error.
      
      Meanwhile fio with aio engine generated a large number of direct IOs,
      which continue allocating spaces in free segment until we run out of them,
      eventually, results in panic in new_curseg as no more free segment was
      found.
      
      So, this patch changes to return EIO in direct_IO for this condition.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      f9811703
    • C
      f2fs: reorganize f2fs_map_blocks · 973163fc
      Chao Yu 提交于
      In this patch, we try to reorganize f2fs_map_blocks to make block mapping
      flow more clear by using following structure:
      
      /* check status of mapping */
      
      if (unmapped) {
      	/* blkaddr == NULL_ADDR || blkaddr == NEW_ADDR */
      
      	if (create) {
      		/* write path, handle dio write case here */
      		alloc_and_map;
      	} else {
      		/*
      		 * handle read cases from all call paths:
      		 *     1. generic read;
      		 *     2. dio read;
      		 *     3. fiemap;
      		 *     4. bmap
      		 */
      	}
      }
      
      /* map buffer_header */
      
      Besides, this patch handles the missing case correctly for dio write:
      When we fail in __allocate_data_blocks, then in f2fs_map_blocks, we will
      not allocate blocks correctly for preallocated blocks, but returning with
      an unmapped buffer head, which will result in failure of dio write.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      973163fc
    • C
      f2fs: fix overflow of size calculation · 9edcdabf
      Chao Yu 提交于
      We have potential overflow issue when calculating size of object, when
      we left shift index with PAGE_CACHE_SHIFT bits, if type of index has only
      32-bits space in 32-bit architecture, left shifting will incur overflow,
      i.e:
      
      pgoff_t index =  0xFFFFFFFF;
      loff_t size = index << PAGE_CACHE_SHIFT;
      size: 0xFFFFF000
      
      So we should cast index with 64-bits type to avoid this issue.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      9edcdabf
  13. 22 8月, 2015 1 次提交
    • C
      f2fs: fix incorrect mapping for bmap · e2b4e2bc
      Chao Yu 提交于
      The test step is like below:
      1. touch file
      2. truncate -s $((1024*1024)) file
      3. fallocate -o 0 -l $((1024*1024)) file
      4. fibmap.f2fs file
      
      Our result of fibmap.f2fs showed below is not correct:
      
      file_pos   start_blk     end_blk        blks
             0    -937166132    -937166132           1
          4096    -937166132    -937166132           1
          8192    -937166132    -937166132           1
         12288    -937166132    -937166132           1
         16384    -937166132    -937166132           1
         20480    -937166132    -937166132           1
      ...
       1040384    -937166132    -937166132           1
       1044480    -937166132    -937166132           1
      
      This is because f2fs_map_blocks will return with no error when meeting
      a hole or preallocated block, the caller __get_data_block will map the
      uninitialized variable value to bh->b_blocknr.
      
      Unfortunately generic_block_bmap will neither check the return value of
      get_data() nor check mapping info of buffer_head, result in returning
      the random block address.
      
      After fixing the issue, our result shows correctly:
      
      file_pos   start_blk     end_blk        blks
             0           0           0         256
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      e2b4e2bc
  14. 21 8月, 2015 1 次提交
    • J
      f2fs: handle failed bio allocation · 740432f8
      Jaegeuk Kim 提交于
      As the below comment of bio_alloc_bioset, f2fs can allocate multiple bios at the
      same time. So, we can't guarantee that bio is allocated all the time.
      
      "
       *   When @bs is not NULL, if %__GFP_WAIT is set then bio_alloc will always be
       *   able to allocate a bio. This is due to the mempool guarantees. To make this
       *   work, callers must never allocate more than 1 bio at a time from this pool.
       *   Callers that need to allocate more than 1 bio must always submit the
       *   previously allocated bio for IO before attempting to allocate a new one.
       *   Failure to do so can cause deadlocks under memory pressure.
      "
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      740432f8
  15. 14 8月, 2015 1 次提交
  16. 12 8月, 2015 2 次提交
    • C
      f2fs: remove inmem radix tree · decd36b6
      Chao Yu 提交于
      Previously, we use radix tree to index all registered page entries for
      atomic file, but now we only use radix tree to see whether current page
      is indexed or not, since the other user of radix tree is gone in commit
      042b7816 ("f2fs: remove unnecessary call to invalidate inmemory pages").
      
      So in this patch, we try to use one more efficient way:
      Introducing a macro ATOMIC_WRITTEN_PAGE, and setting it as page private
      value to indicate page indexing status. By using this way, we can save
      memory and lookup time.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      decd36b6
    • C
      f2fs: report EINVAL for unalignment direct IO · c15e8599
      Chao Yu 提交于
      We run ltp testcase with f2fs and obtain a TFAIL in diotest4, the result in
      detail is as fallow:
      
      dio04
      
      <<<test_start>>>
      tag=dio04 stime=1432278894
      cmdline="diotest4"
      contacts=""
      analysis=exit
      <<<test_output>>>
      diotest4    1  TPASS  :  Negative Offset
      diotest4    2  TPASS  :  removed
      diotest4    3  TFAIL  :  diotest4.c:129: write allows odd count.returns 1: Success
      diotest4    4  TFAIL  :  diotest4.c:183: Odd count of read and write
      diotest4    5  TPASS  :  Read beyond the file size
      ......
      
      the result of ext4 with same environment:
      
      dio04
      
      <<<test_start>>>
      tag=dio04 stime=1432259643
      cmdline="diotest4"
      contacts=""
      analysis=exit
      <<<test_output>>>
      diotest4    1  TPASS  :  Negative Offset
      diotest4    2  TPASS  :  removed
      diotest4    3  TPASS  :  Odd count of read and write
      diotest4    4  TPASS  :  Read beyond the file size
      ......
      
      The reason is that when triggering DIO in f2fs, we will return zero value
      in ->direct_IO if writer's buffer offset, file offset and transfer size is
      not alignment to block size of filesystem, resulting in falling back into
      buffered write instead of returning -EINVAL.
      
      This patch fixes that problem by returning correct error number for above
      case, and removing the judgement condition in check_direct_IO to make sure
      the verification will be enabled for direct reader too.
      
      Besides, Jaegeuk Kim pointed out that there is expectional cases we should
      always make direct-io falling back into buffered write, such as dio in
      encrypted file.
      Signed-off-by: NYunlei He <heyunlei@huawei.com>
      [Chao Yu make small change and add detail description in commit message]
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      c15e8599
  17. 06 8月, 2015 1 次提交
  18. 05 8月, 2015 3 次提交