1. 28 2月, 2017 2 次提交
  2. 24 2月, 2017 1 次提交
    • C
      f2fs: change recovery policy of xattr node block · d260081c
      Chao Yu 提交于
      Currently, if we call fsync after updating the xattr date belongs to the
      file, f2fs needs to trigger checkpoint to keep xattr data consistent. But,
      this policy cause low performance as checkpoint will block most foreground
      operations and cause unneeded and unrelated IOs around checkpoint.
      
      This patch will reuse regular file recovery policy for xattr node block,
      so, we change to write xattr node block tagged with fsync flag to warm
      area instead of cold area, and during recovery, we search warm node chain
      for fsynced xattr block, and do the recovery.
      
      So, for below application IO pattern, performance can be improved
      obviously:
      - touch file
      - create/update/delete xattr entry in file
      - fsync file
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      d260081c
  3. 23 2月, 2017 1 次提交
    • C
      f2fs: enhance lookup xattr · ba38c27e
      Chao Yu 提交于
      Previously, in getxattr we will load all entries both in inline xattr and
      xattr node block, and then do the lookup in all entries, but our lookup
      flow shows low efficiency, since if we can lookup and hit in inline xattr
      of inode page cache first, we don't need to load and lookup xattr node
      block, which can obviously save cpu time and IO latency.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      [Jaegeuk Kim: initialize NULL to avoid warning]
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      ba38c27e
  4. 24 11月, 2016 1 次提交
  5. 28 9月, 2016 1 次提交
  6. 23 9月, 2016 1 次提交
  7. 08 9月, 2016 1 次提交
    • J
      f2fs: fix lost xattrs of directories · bbf156f7
      Jaegeuk Kim 提交于
      This patch enhances the xattr consistency of dirs from suddern power-cuts.
      
      Possible scenario would be:
      1. dir->setxattr used by per-file encryption
      2. file->setxattr goes into inline_xattr
      3. file->fsync
      
      In that case, we should do checkpoint for #1.
      Otherwise we'd lose dir's key information for the file given #2.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      bbf156f7
  8. 09 7月, 2016 2 次提交
  9. 03 6月, 2016 3 次提交
  10. 28 5月, 2016 1 次提交
  11. 08 5月, 2016 1 次提交
  12. 15 4月, 2016 1 次提交
  13. 11 4月, 2016 1 次提交
  14. 23 2月, 2016 1 次提交
  15. 12 1月, 2016 1 次提交
  16. 09 1月, 2016 1 次提交
  17. 14 12月, 2015 1 次提交
  18. 07 12月, 2015 1 次提交
  19. 14 11月, 2015 2 次提交
  20. 05 8月, 2015 1 次提交
    • C
      f2fs: correct return value of ->setxattr · 037fe70c
      Chao Yu 提交于
      This patch fixes to return correct error number of ->setxattr, which
      is reported by xfstest tests/generic/026 as below:
      
      generic/026      - output mismatch
          --- tests/generic/026.out
          +++ results/generic/026.out.bad
          @@ -4,6 +4,6 @@
           1 below acl max
           acl max
           1 above acl max
          -chacl: cannot set access acl on "largeaclfile": Argument list too long
          +chacl: cannot set access acl on "largeaclfile": Numerical result out of range
           use 16 aces
           use 17 aces
          ...
      Ran: generic/026
      Failures: generic/026
      Failed 1 of 1 tests
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      037fe70c
  21. 29 5月, 2015 1 次提交
  22. 16 4月, 2015 1 次提交
  23. 11 4月, 2015 2 次提交
    • C
      f2fs: persist system.advise into on-disk inode · 30c62fdb
      Chao Yu 提交于
      This patch fixes to dirty inode for persisting i_advise of f2fs inode info into
      on-disk inode if user sets system.advise through setxattr. Otherwise the new
      value will be lost.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      30c62fdb
    • C
      f2fs: avoid NULL pointer dereference in f2fs_xattr_advise_get · 84e97c27
      Chao Yu 提交于
      We will encounter oops by executing below command.
      getfattr -n system.advise /mnt/f2fs/file
      Killed
      
      message log:
      BUG: unable to handle kernel NULL pointer dereference at   (null)
      IP: [<f8b54d69>] f2fs_xattr_advise_get+0x29/0x40 [f2fs]
      *pdpt = 00000000319b7001 *pde = 0000000000000000
      Oops: 0002 [#1] SMP
      Modules linked in: f2fs(O) snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq joydev
      snd_seq_device snd_timer bnep snd rfcomm microcode bluetooth soundcore i2c_piix4 mac_hid serio_raw parport_pc ppdev lp parport
      binfmt_misc hid_generic psmouse usbhid hid e1000 [last unloaded: f2fs]
      CPU: 3 PID: 3134 Comm: getfattr Tainted: G           O    4.0.0-rc1 #6
      Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      task: f3a71b60 ti: f19a6000 task.ti: f19a6000
      EIP: 0060:[<f8b54d69>] EFLAGS: 00010246 CPU: 3
      EIP is at f2fs_xattr_advise_get+0x29/0x40 [f2fs]
      EAX: 00000000 EBX: f19a7e71 ECX: 00000000 EDX: f8b5b467
      ESI: 00000000 EDI: f2008570 EBP: f19a7e14 ESP: f19a7e08
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      CR0: 80050033 CR2: 00000000 CR3: 319b8000 CR4: 000007f0
      Stack:
       f8b5a634 c0cbb580 00000000 f19a7e34 c1193850 00000000 00000007 f19a7e71
       f19a7e64 c0cbb580 c1193810 f19a7e50 c1193c00 00000000 00000000 00000000
       c0cbb580 00000000 f19a7f70 c1194097 00000000 00000000 00000000 74737973
      Call Trace:
       [<c1193850>] generic_getxattr+0x40/0x50
       [<c1193810>] ? xattr_resolve_name+0x80/0x80
       [<c1193c00>] vfs_getxattr+0x70/0xa0
       [<c1194097>] getxattr+0x87/0x190
       [<c11801d7>] ? path_lookupat+0x57/0x5f0
       [<c11819d2>] ? putname+0x32/0x50
       [<c116653a>] ? kmem_cache_alloc+0x2a/0x130
       [<c11819d2>] ? putname+0x32/0x50
       [<c11819d2>] ? putname+0x32/0x50
       [<c11819d2>] ? putname+0x32/0x50
       [<c11827f9>] ? user_path_at_empty+0x49/0x70
       [<c118283f>] ? user_path_at+0x1f/0x30
       [<c11941e7>] path_getxattr+0x47/0x80
       [<c11948e7>] SyS_getxattr+0x27/0x30
       [<c163f748>] sysenter_do_call+0x12/0x12
      Code: 66 90 55 89 e5 57 56 53 66 66 66 66 90 8b 78 20 89 d3 ba 67 b4 b5 f8 89 d8 89 ce e8 42 7c 7b c8 85 c0 75 16 0f b6 87 44 01 00
      00 <88> 06 b8 01 00 00 00 5b 5e 5f 5d c3 8d 76 00 b8 ea ff ff ff eb
      EIP: [<f8b54d69>] f2fs_xattr_advise_get+0x29/0x40 [f2fs] SS:ESP 0068:f19a7e08
      CR2: 0000000000000000
      ---[ end trace 860260654f1f416a ]---
      
      The reason is that in getfattr there are two steps which is indicated by strace info:
      1) try to lookup and get size of specified xattr.
      2) get value of the extented attribute.
      
      strace info:
      getxattr("/mnt/f2fs/file", "system.advise", 0x0, 0) = 1
      getxattr("/mnt/f2fs/file", "system.advise", "\x00", 256) = 1
      
      For the first step, getfattr may pass a NULL pointer in @value and zero in @size
      as parameters for ->getxattr, but we access this @value pointer directly without
      checking whether the pointer is valid or not in f2fs_xattr_advise_get, so the
      oops occurs.
      
      This patch fixes this issue by verifying @value pointer before using.
      Signed-off-by: NChao Yu <chao2.yu@samsung.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      84e97c27
  24. 04 11月, 2014 1 次提交
    • J
      f2fs: avoid deadlock on init_inode_metadata · bce8d112
      Jaegeuk Kim 提交于
      Previously, init_inode_metadata does not hold any parent directory's inode
      page. So, f2fs_init_acl can grab its parent inode page without any problem.
      But, when we use inline_dentry, that page is grabbed during f2fs_add_link,
      so that we can fall into deadlock condition like below.
      
      INFO: task mknod:11006 blocked for more than 120 seconds.
            Tainted: G           OE  3.17.0-rc1+ #13
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      mknod           D ffff88003fc94580     0 11006  11004 0x00000000
       ffff880007717b10 0000000000000002 ffff88003c323220 ffff880007717fd8
       0000000000014580 0000000000014580 ffff88003daecb30 ffff88003c323220
       ffff88003fc94e80 ffff88003ffbb4e8 ffff880007717ba0 0000000000000002
      Call Trace:
       [<ffffffff8173dc40>] ? bit_wait+0x50/0x50
       [<ffffffff8173d4cd>] io_schedule+0x9d/0x130
       [<ffffffff8173dc6c>] bit_wait_io+0x2c/0x50
       [<ffffffff8173da3b>] __wait_on_bit_lock+0x4b/0xb0
       [<ffffffff811640a7>] __lock_page+0x67/0x70
       [<ffffffff810acf50>] ? autoremove_wake_function+0x40/0x40
       [<ffffffff811652cc>] pagecache_get_page+0x14c/0x1e0
       [<ffffffffa029afa9>] get_node_page+0x59/0x130 [f2fs]
       [<ffffffffa02a63ad>] read_all_xattrs+0x24d/0x430 [f2fs]
       [<ffffffffa02a6ca2>] f2fs_getxattr+0x52/0xe0 [f2fs]
       [<ffffffffa02a7481>] f2fs_get_acl+0x41/0x2d0 [f2fs]
       [<ffffffff8122d847>] get_acl+0x47/0x70
       [<ffffffff8122db5a>] posix_acl_create+0x5a/0x150
       [<ffffffffa02a7759>] f2fs_init_acl+0x29/0xcb [f2fs]
       [<ffffffffa0286a8d>] init_inode_metadata+0x5d/0x340 [f2fs]
       [<ffffffffa029253a>] f2fs_add_inline_entry+0x12a/0x2e0 [f2fs]
       [<ffffffffa0286ea5>] __f2fs_add_link+0x45/0x4a0 [f2fs]
       [<ffffffffa028b5b6>] ? f2fs_new_inode+0x146/0x220 [f2fs]
       [<ffffffffa028b816>] f2fs_mknod+0x86/0xf0 [f2fs]
       [<ffffffff811e3ec1>] vfs_mknod+0xe1/0x160
       [<ffffffff811e4b26>] SyS_mknod+0x1f6/0x200
       [<ffffffff81741d7f>] tracesys+0xe1/0xe6
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      bce8d112
  25. 10 9月, 2014 1 次提交
  26. 04 9月, 2014 1 次提交
  27. 20 8月, 2014 1 次提交
  28. 02 6月, 2014 1 次提交
    • J
      f2fs: fix recursive lock by f2fs_setxattr · d631abda
      Jaegeuk Kim 提交于
      This patch should resolve the following recursive lock.
      
      [<ffffffff8135a9c3>] call_rwsem_down_write_failed+0x13/0x20
      [<ffffffffa01749dc>] f2fs_setxattr+0x5c/0xa0 [f2fs]
      [<ffffffffa0174c99>] __f2fs_set_acl+0x1b9/0x340 [f2fs]
      [<ffffffffa017515a>] f2fs_init_acl+0x4a/0xcb [f2fs]
      [<ffffffffa0159abe>] __f2fs_add_link+0x26e/0x780 [f2fs]
      [<ffffffffa015d4d8>] f2fs_mkdir+0xb8/0x150 [f2fs]
      [<ffffffff811cebd7>] vfs_mkdir+0xb7/0x160
      [<ffffffff811cf89b>] SyS_mkdir+0xab/0xe0
      [<ffffffff817244bf>] tracesys+0xe1/0xe6
      [<ffffffffffffffff>] 0xffffffffffffffff
      
      The call path indicates:
      - f2fs_add_link
         : down_write(&fi->i_sem);
      
       - init_inode_metadata
         - f2fs_init_acl
           - __f2fs_set_acl
             - f2fs_setxattr
               : down_write(&fi->i_sem);
      
      Here we should not call f2fs_setxattr, but __f2fs_setxattr.
      But __f2fs_setxattr is a static function in xattr.c, so that I found the other
      generic approach to use f2fs_setxattr.
      
      In f2fs_setxattr, the page pointer is only given from init_inode_metadata.
      So, this patch adds this condition to avoid this in f2fs_setxattr.
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      d631abda
  29. 07 5月, 2014 4 次提交
  30. 01 4月, 2014 1 次提交
  31. 20 3月, 2014 1 次提交
    • J
      f2fs: avoid RECLAIM_FS-ON-W warning · 808a1d74
      Jaegeuk Kim 提交于
      This patch should resolve the following possible bug.
      
      RECLAIM_FS-ON-W at:
       mark_held_locks+0xb9/0x140
       lockdep_trace_alloc+0x85/0xf0
       __kmalloc+0x53/0x1d0
       read_all_xattrs+0x3d1/0x3f0 [f2fs]
       f2fs_getxattr+0x4f/0x100 [f2fs]
       f2fs_get_acl+0x4c/0x290 [f2fs]
       get_acl+0x4f/0x80
       posix_acl_create+0x72/0x180
       f2fs_init_acl+0x29/0xcc [f2fs]
       __f2fs_add_link+0x259/0x710 [f2fs]
       f2fs_create+0xad/0x1c0 [f2fs]
       vfs_create+0xed/0x150
       do_last+0xd36/0xed0
       path_openat+0xc5/0x680
       do_filp_open+0x43/0xa0
       do_sys_open+0x13c/0x230
       SyS_creat+0x1e/0x20
       system_call_fastpath+0x16/0x1b
      Signed-off-by: NJaegeuk Kim <jaegeuk.kim@samsung.com>
      808a1d74