1. 30 8月, 2016 10 次提交
  2. 25 8月, 2016 2 次提交
    • J
      f2fs: do not use discard_map for hard disks · 3e025740
      Jaegeuk Kim 提交于
      We don't need to keep discard_map, if disk does not support discard command.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      3e025740
    • Y
      f2fs: not allow to write illegal blkaddr · bb413d6a
      Yunlei He 提交于
      we came across an error as below:
      
      [build_nat_area_bitmap:1710] nid[0x    1718] addr[0x         1c18ddc] ino[0x    1718]
      [build_nat_area_bitmap:1710] nid[0x    1719] addr[0x         1c193d5] ino[0x    1719]
      [build_nat_area_bitmap:1710] nid[0x    171a] addr[0x         1c1736e] ino[0x    171a]
      [build_nat_area_bitmap:1710] nid[0x    171b] addr[0x        58b3ee8f] ino[0x815f92ed]
      [build_nat_area_bitmap:1710] nid[0x    171c] addr[0x         fcdc94b] ino[0x49366377]
      [build_nat_area_bitmap:1710] nid[0x    171d] addr[0x        7cd2facf] ino[0xb3c55300]
      [build_nat_area_bitmap:1710] nid[0x    171e] addr[0x        bd4e25d0] ino[0x77c34c09]
      
      ... ...
      
      [build_nat_area_bitmap:1710] nid[0x    1718] addr[0x         1c18ddc] ino[0x    1718]
      [build_nat_area_bitmap:1710] nid[0x    1719] addr[0x         1c193d5] ino[0x    1719]
      [build_nat_area_bitmap:1710] nid[0x    171a] addr[0x         1c1736e] ino[0x    171a]
      [build_nat_area_bitmap:1710] nid[0x    171b] addr[0x        58b3ee8f] ino[0x815f92ed]
      [build_nat_area_bitmap:1710] nid[0x    171c] addr[0x         fcdc94b] ino[0x49366377]
      [build_nat_area_bitmap:1710] nid[0x    171d] addr[0x        7cd2facf] ino[0xb3c55300]
      [build_nat_area_bitmap:1710] nid[0x    171e] addr[0x        bd4e25d0] ino[0x77c34c09]
      
      One nat block may be stepped by a data block, so this patch forbid to
      write if the blkaddr is illegal
      Signed-off-by: NYunlei He <heyunlei@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      bb413d6a
  3. 19 8月, 2016 4 次提交
  4. 05 8月, 2016 1 次提交
  5. 31 7月, 2016 1 次提交
  6. 27 7月, 2016 1 次提交
    • M
      mm, memcg: use consistent gfp flags during readahead · 8a5c743e
      Michal Hocko 提交于
      Vladimir has noticed that we might declare memcg oom even during
      readahead because read_pages only uses GFP_KERNEL (with mapping_gfp
      restriction) while __do_page_cache_readahead uses
      page_cache_alloc_readahead which adds __GFP_NORETRY to prevent from
      OOMs.  This gfp mask discrepancy is really unfortunate and easily
      fixable.  Drop page_cache_alloc_readahead() which only has one user and
      outsource the gfp_mask logic into readahead_gfp_mask and propagate this
      mask from __do_page_cache_readahead down to read_pages.
      
      This alone would have only very limited impact as most filesystems are
      implementing ->readpages and the common implementation mpage_readpages
      does GFP_KERNEL (with mapping_gfp restriction) again.  We can tell it to
      use readahead_gfp_mask instead as this function is called only during
      readahead as well.  The same applies to read_cache_pages.
      
      ext4 has its own ext4_mpage_readpages but the path which has pages !=
      NULL can use the same gfp mask.  Btrfs, cifs, f2fs and orangefs are
      doing a very similar pattern to mpage_readpages so the same can be
      applied to them as well.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [mhocko@suse.com: restrict gfp mask in mpage_alloc]
        Link: http://lkml.kernel.org/r/20160610074223.GC32285@dhcp22.suse.cz
      Link: http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Cc: Vladimir Davydov <vdavydov@parallels.com>
      Cc: Chris Mason <clm@fb.com>
      Cc: Steve French <sfrench@samba.org>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Mike Marshall <hubcap@omnibond.com>
      Cc: Jaegeuk Kim <jaegeuk@kernel.org>
      Cc: Changman Lee <cm224.lee@samsung.com>
      Cc: Chao Yu <yuchao0@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8a5c743e
  7. 26 7月, 2016 1 次提交
  8. 23 7月, 2016 1 次提交
    • Y
      f2fs: get victim segment again after new cp · fe94793e
      Yunlei He 提交于
      Previous selected segment may become free after write_checkpoint,
      if we do garbage collect on this segment, and then new_curseg happen
      to reuse it, it may cause f2fs_bug_on as below.
      
      	panic+0x154/0x29c
      	do_garbage_collect+0x15c/0xaf4
      	f2fs_gc+0x2dc/0x444
      	f2fs_balance_fs.part.22+0xcc/0x14c
      	f2fs_balance_fs+0x28/0x34
      	f2fs_map_blocks+0x5ec/0x790
      	f2fs_preallocate_blocks+0xe0/0x100
      	f2fs_file_write_iter+0x64/0x11c
      	new_sync_write+0xac/0x11c
      	vfs_write+0x144/0x1e4
      	SyS_write+0x60/0xc0
      
      Here, maybe we check sit and ssa type during reset_curseg. So, we check
      segment is stale or not, and select a new victim to avoid this.
      Signed-off-by: NYunlei He <heyunlei@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      fe94793e
  9. 21 7月, 2016 5 次提交
  10. 19 7月, 2016 1 次提交
  11. 16 7月, 2016 7 次提交
  12. 09 7月, 2016 6 次提交