1. 22 3月, 2017 2 次提交
    • K
      f2fs: fix bad prefetchw of NULL page · a83d50bc
      Kinglong Mee 提交于
      For f2fs_read_data_pages, the f2fs_mpage_readpages gets "page == NULL",
      so that, the prefetchw(&page->flags) is operated on NULL.
      
      Fixes: f1e88660 ("f2fs: expose f2fs_mpage_readpages")
      Signed-off-by: NKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      a83d50bc
    • J
      f2fs: fix stale ATOMIC_WRITTEN_PAGE private pointer · 8c242db9
      Jaegeuk Kim 提交于
      When I forced to enable atomic operations intentionally, I could hit the below
      panic, since we didn't clear page->private in f2fs_invalidate_page called by
      file truncation.
      
      The panic occurs due to NULL mapping having page->private.
      
      BUG: unable to handle kernel paging request at ffffffffffffffff
      IP: drop_buffers+0x38/0xe0
      PGD 5d00c067
      PUD 5d00e067
      PMD 0
      CPU: 3 PID: 1648 Comm: fsstress Tainted: G      D    OE   4.10.0+ #5
      Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      task: ffff9151952863c0 task.stack: ffffaaec40db4000
      RIP: 0010:drop_buffers+0x38/0xe0
      RSP: 0018:ffffaaec40db74c8 EFLAGS: 00010292
      Call Trace:
       ? page_referenced+0x8b/0x170
       try_to_free_buffers+0xc5/0xe0
       try_to_release_page+0x49/0x50
       shrink_page_list+0x8bc/0x9f0
       shrink_inactive_list+0x1dd/0x500
       ? shrink_active_list+0x2c0/0x430
       shrink_node_memcg+0x5eb/0x7c0
       shrink_node+0xe1/0x320
       do_try_to_free_pages+0xef/0x2e0
       try_to_free_pages+0xe9/0x190
       __alloc_pages_slowpath+0x390/0xe70
       __alloc_pages_nodemask+0x291/0x2b0
       alloc_pages_current+0x95/0x140
       __page_cache_alloc+0xc4/0xe0
       pagecache_get_page+0xab/0x2a0
       grab_cache_page_write_begin+0x20/0x40
       get_read_data_page+0x2e6/0x4c0 [f2fs]
       ? f2fs_mark_inode_dirty_sync+0x16/0x30 [f2fs]
       ? truncate_data_blocks_range+0x238/0x2b0 [f2fs]
       get_lock_data_page+0x30/0x190 [f2fs]
       __exchange_data_block+0xaaf/0xf40 [f2fs]
       f2fs_fallocate+0x418/0xd00 [f2fs]
       vfs_fallocate+0x157/0x220
       SyS_fallocate+0x48/0x80
      Signed-off-by: NYunlei He <heyunlei@huawei.com>
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      [Chao Yu: use INMEM_INVALIDATE for better tracing]
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      8c242db9
  2. 02 3月, 2017 1 次提交
  3. 28 2月, 2017 5 次提交
  4. 24 2月, 2017 5 次提交
  5. 23 2月, 2017 4 次提交
  6. 29 1月, 2017 3 次提交
  7. 12 12月, 2016 1 次提交
  8. 30 11月, 2016 1 次提交
  9. 26 11月, 2016 6 次提交
  10. 24 11月, 2016 6 次提交
  11. 14 11月, 2016 2 次提交
  12. 03 11月, 2016 1 次提交
  13. 01 11月, 2016 1 次提交
  14. 12 10月, 2016 1 次提交
  15. 01 10月, 2016 1 次提交
    • C
      f2fs: don't submit irrelevant page · 6ca56ca4
      Chao Yu 提交于
      While we call ->writepages, there are two cases:
      a. we didn't writeout any dirty pages, since they are writebacked by other
      thread concurrently.
      b. we writeout dirty pages, and have already submitted bio to block layer.
      
      In these cases, we don't need to do additional bio flushing unnecessarily,
      it may split bio in cache into smaller one.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      6ca56ca4