1. 24 11月, 2016 2 次提交
  2. 01 10月, 2016 1 次提交
    • C
      f2fs: support configuring fault injection per superblock · 1ecc0c5c
      Chao Yu 提交于
      Previously, we only support global fault injection configuration, so that
      when we configure type/rate of fault injection through sysfs, mount
      option, it will influence all f2fs partition which is being used.
      
      It is not make sence, since it will be not convenient if developer want
      to test separated partitions with different fault injection rate/type
      simultaneously, also it's not possible to enable fault injection in one
      partition and disable fault injection in other one.
      
      >From now on, we move global configuration of fault injection in module
      into per-superblock, hence injection testing can be more flexible.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      1ecc0c5c
  3. 14 9月, 2016 1 次提交
  4. 09 7月, 2016 1 次提交
  5. 07 7月, 2016 1 次提交
  6. 08 6月, 2016 2 次提交
  7. 03 6月, 2016 5 次提交
  8. 21 5月, 2016 1 次提交
  9. 08 5月, 2016 3 次提交
  10. 18 3月, 2016 1 次提交
    • J
      fs crypto: move per-file encryption from f2fs tree to fs/crypto · 0b81d077
      Jaegeuk Kim 提交于
      This patch adds the renamed functions moved from the f2fs crypto files.
      
      1. definitions for per-file encryption used by ext4 and f2fs.
      
      2. crypto.c for encrypt/decrypt functions
       a. IO preparation:
        - fscrypt_get_ctx / fscrypt_release_ctx
       b. before IOs:
        - fscrypt_encrypt_page
        - fscrypt_decrypt_page
        - fscrypt_zeroout_range
       c. after IOs:
        - fscrypt_decrypt_bio_pages
        - fscrypt_pullback_bio_page
        - fscrypt_restore_control_page
      
      3. policy.c supporting context management.
       a. For ioctls:
        - fscrypt_process_policy
        - fscrypt_get_policy
       b. For context permission
        - fscrypt_has_permitted_context
        - fscrypt_inherit_context
      
      4. keyinfo.c to handle permissions
        - fscrypt_get_encryption_info
        - fscrypt_free_encryption_info
      
      5. fname.c to support filename encryption
       a. general wrapper functions
        - fscrypt_fname_disk_to_usr
        - fscrypt_fname_usr_to_disk
        - fscrypt_setup_filename
        - fscrypt_free_filename
      
       b. specific filename handling functions
        - fscrypt_fname_alloc_buffer
        - fscrypt_fname_free_buffer
      
      6. Makefile and Kconfig
      
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Signed-off-by: NMichael Halcrow <mhalcrow@google.com>
      Signed-off-by: NIldar Muslukhov <ildarm@google.com>
      Signed-off-by: NUday Savagaonkar <savagaon@google.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      0b81d077
  11. 23 2月, 2016 3 次提交
  12. 09 1月, 2016 2 次提交
  13. 31 12月, 2015 1 次提交
    • J
      f2fs: load largest extent all the time · ed3d1256
      Jaegeuk Kim 提交于
      Otherwise, we can get mismatched largest extent information.
      
      One example is:
      1. mount f2fs w/ extent_cache
      2. make a small extent
      3. umount
      4. mount f2fs w/o extent_cache
      5. update the largest extent
      6. umount
      7. mount f2fs w/ extent_cache
      8. get the old extent made by #2
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      ed3d1256
  14. 17 12月, 2015 1 次提交
  15. 16 12月, 2015 1 次提交
  16. 09 12月, 2015 1 次提交
    • A
      don't put symlink bodies in pagecache into highmem · 21fc61c7
      Al Viro 提交于
      kmap() in page_follow_link_light() needed to go - allowing to hold
      an arbitrary number of kmaps for long is a great way to deadlocking
      the system.
      
      new helper (inode_nohighmem(inode)) needs to be used for pagecache
      symlinks inodes; done for all in-tree cases.  page_follow_link_light()
      instrumented to yell about anything missed.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      21fc61c7
  17. 10 10月, 2015 1 次提交
  18. 25 8月, 2015 2 次提交
    • C
      f2fs: fix to release inode correctly · 13ec7297
      Chao Yu 提交于
      In following call stack, if unfortunately we lose all chances to truncate
      inode page in remove_inode_page, eventually we will add the nid allocated
      previously into free nid cache, this nid is with NID_NEW status and with
      NEW_ADDR in its blkaddr pointer:
      
       - f2fs_create
        - f2fs_add_link
         - __f2fs_add_link
          - init_inode_metadata
           - new_inode_page
            - new_node_page
             - set_node_addr(, NEW_ADDR)
           - f2fs_init_acl   failed
           - remove_inode_page  failed
        - handle_failed_inode
         - remove_inode_page  failed
         - iput
          - f2fs_evict_inode
           - remove_inode_page  failed
           - alloc_nid_failed   cache a nid with valid blkaddr: NEW_ADDR
      
      This may not only cause resource leak of previous inode, but also may cause
      incorrect use of the previous blkaddr which is located in NO.nid node entry
      when this nid is reused by others.
      
      This patch tries to add this inode to orphan list if we fail to truncate
      inode, so that we can obtain a second chance to release it in orphan
      recovery flow.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      13ec7297
    • Z
      f2fs: atomically set inode->i_flags · 6a678857
      Zhang Zhen 提交于
      According to commit 5f16f322 ("ext4: atomically set inode->i_flags in
      ext4_set_inode_flags()").
      Signed-off-by: NZhang Zhen <zhenzhang.zhang@huawei.com>
      Reviewed-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      6a678857
  19. 05 8月, 2015 5 次提交
  20. 02 6月, 2015 1 次提交
    • J
      f2fs crypto: use per-inode tfm structure · 26bf3dc7
      Jaegeuk Kim 提交于
      This patch applies the following ext4 patch:
      
        ext4 crypto: use per-inode tfm structure
      
      As suggested by Herbert Xu, we shouldn't allocate a new tfm each time
      we read or write a page.  Instead we can use a single tfm hanging off
      the inode's crypt_info structure for all of our encryption needs for
      that inode, since the tfm can be used by multiple crypto requests in
      parallel.
      
      Also use cmpxchg() to avoid races that could result in crypt_info
      structure getting doubly allocated or doubly freed.
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      26bf3dc7
  21. 29 5月, 2015 2 次提交
  22. 11 4月, 2015 2 次提交