diff mbox series

[v2] fuse: Track process write operations in both direct and writethrough modes

Message ID 20231107081350.14472-1-zhoujifeng@kylinos.com.cn (mailing list archive)
State New, archived
Headers show
Series [v2] fuse: Track process write operations in both direct and writethrough modes | expand

Commit Message

周继峰 Nov. 7, 2023, 8:13 a.m. UTC 
Due to the fact that fuse does not count the write IO of processes in the
direct and writethrough write modes, user processes cannot track
write_bytes through the “/proc/[pid]/io” path. For example, the system
tool iotop cannot count the write operations of the corresponding process.

Signed-off-by: Zhou Jifeng <zhoujifeng@kylinos.com.cn>
---
v1 -> v2: Fix "Miss error code" issue

 fs/fuse/file.c | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

kernel test robot Nov. 16, 2023, 8:42 a.m. UTC | #1 
Hello,

kernel test robot noticed "BUG:KASAN:slab-out-of-bounds_in_fuse_evict_inode" on:

commit: 6772e9ddfc996544d6a22e72eddf7510ac2999fc ("[PATCH v2] fuse: Track process write operations in both direct and writethrough modes")
url: https://github.com/intel-lab-lkp/linux/commits/Zhou-Jifeng/fuse-Track-process-write-operations-in-both-direct-and-writethrough-modes/20231107-163300
base: https://git.kernel.org/cgit/linux/kernel/git/mszeredi/fuse.git for-next
patch link: https://lore.kernel.org/all/20231107081350.14472-1-zhoujifeng@kylinos.com.cn/
patch subject: [PATCH v2] fuse: Track process write operations in both direct and writethrough modes

in testcase: ltp
version: ltp-x86_64-14c1f76-1_20230715
with following parameters:

	disk: 1HDD
	fs: xfs
	test: fs-03



compiler: gcc-12
test machine: 4 threads 1 sockets Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (Ivy Bridge) with 8G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)



If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202311161627.5a936995-oliver.sang@intel.com



The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20231116/202311161627.5a936995-oliver.sang@intel.com


[  608.279527][ T5411] ==================================================================
[  608.279697][ T5411] BUG: KASAN: slab-out-of-bounds in fuse_evict_inode+0x15c/0x4a0 [fuse]
[  608.279871][ T5411] Write of size 4 at addr ffff888092af0dc8 by task fs_fill/5411
[  608.280019][ T5411] 
[  608.280082][ T5411] CPU: 1 PID: 5411 Comm: fs_fill Not tainted 6.6.0-rc2-00004-g6772e9ddfc99 #1
[  608.280252][ T5411] Hardware name: Hewlett-Packard p6-1451cx/2ADA, BIOS 8.15 02/05/2013
[  608.280409][ T5411] Call Trace:
[  608.280494][ T5411]  <TASK>
[  608.280570][ T5411]  dump_stack_lvl+0x36/0x50
[  608.280674][ T5411]  print_address_description+0x2c/0x3a0
[  608.280808][ T5411]  ? fuse_evict_inode+0x15c/0x4a0 [fuse]
[  608.280935][ T5411]  print_report+0xba/0x2b0
[  608.281034][ T5411]  ? kasan_addr_to_slab+0xd/0x90
[  608.281140][ T5411]  ? fuse_evict_inode+0x15c/0x4a0 [fuse]
[  608.281266][ T5411]  kasan_report+0xc7/0x100
[  608.281604][ T5411]  ? fuse_evict_inode+0x15c/0x4a0 [fuse]
[  608.281763][ T5411]  kasan_check_range+0xfc/0x1a0
[  608.281871][ T5411]  fuse_evict_inode+0x15c/0x4a0 [fuse]
[  608.281994][ T5411]  evict+0x29b/0x5e0
[  608.282086][ T5411]  ? lookup_one_qstr_excl+0x23/0x150
[  608.282201][ T5411]  do_unlinkat+0x34f/0x5a0
[  608.282300][ T5411]  ? __x64_sys_rmdir+0xf0/0xf0
[  608.282404][ T5411]  ? 0xffffffff81000000
[  608.282498][ T5411]  ? strncpy_from_user+0x6a/0x230
[  608.282611][ T5411]  ? getname_flags+0x8d/0x430
[  608.282724][ T5411]  __x64_sys_unlink+0xa9/0xf0
[  608.282827][ T5411]  do_syscall_64+0x38/0x80
[  608.282928][ T5411]  entry_SYSCALL_64_after_hwframe+0x5e/0xc8
[  608.283052][ T5411] RIP: 0033:0x7f6ba18898a7
[  608.283574][ T5411] Code: f0 ff ff 73 01 c3 48 8b 0d 56 85 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 57 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 29 85 0d 00 f7 d8 64 89 01 48
[  608.283947][ T5411] RSP: 002b:00007f6ba178ae48 EFLAGS: 00000246 ORIG_RAX: 0000000000000057
[  608.284142][ T5411] RAX: ffffffffffffffda RBX: 00007f6b94000b70 RCX: 00007f6ba18898a7
[  608.284321][ T5411] RDX: 0000000000000000 RSI: 0000000000000039 RDI: 00007f6ba178ae90
[  608.284503][ T5411] RBP: 00007f6ba178ae90 R08: 0000000000000000 R09: 0000000000000073
[  608.284681][ T5411] R10: 0000000000000000 R11: 0000000000000246 R12: 0000562b20532004
[  608.284862][ T5411] R13: 0000000000000039 R14: 0000000000000000 R15: 00007f6ba178ae90
[  608.285050][ T5411]  </TASK>
[  608.285150][ T5411] 
[  608.285237][ T5411] The buggy address belongs to the object at ffff888092af0b40
[  608.285237][ T5411]  which belongs to the cache fuse_inode of size 824
[  608.285514][ T5411] The buggy address is located 648 bytes inside of
[  608.285514][ T5411]  allocated 824-byte region [ffff888092af0b40, ffff888092af0e78)
[  608.285794][ T5411] 
[  608.285883][ T5411] The buggy address belongs to the physical page:
[  608.286036][ T5411] page:00000000c8edd8aa refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x92af0
[  608.286258][ T5411] head:00000000c8edd8aa order:2 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[  608.286455][ T5411] memcg:ffff8881f087ff01
[  608.286572][ T5411] flags: 0xfffffc0000840(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
[  608.286753][ T5411] page_type: 0xffffffff()
[  608.286867][ T5411] raw: 000fffffc0000840 ffff8881019c9e00 dead000000000122 0000000000000000
[  608.287685][ T5411] raw: 0000000000000000 0000000080110011 00000001ffffffff ffff8881f087ff01
[  608.287877][ T5411] page dumped because: kasan: bad access detected
[  608.288035][ T5411] 
[  608.288121][ T5411] Memory state around the buggy address:
[  608.288261][ T5411]  ffff888092af0c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  608.288443][ T5411]  ffff888092af0d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  608.288624][ T5411] >ffff888092af0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  608.288803][ T5411]                                               ^
[  608.288932][  T291] tst_fill_fs.c:126: TINFO: writev("mntpoint/subdir/thread4/AOF", iov, 512): ENOSPC
[  608.288950][ T5411]  ffff888092af0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  608.288953][ T5411]  ffff888092af0e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  608.288984][  T291] 
[  608.289107][ T5411] ==================================================================
[  608.289285][ T5411] Disabling lock debugging due to kernel taint
周继峰 Nov. 17, 2023, 3:06 a.m. UTC | #2 
Hi Miklos,

On Thu, Nov 16, 2023 at 4:43 PM kernel test robot <oliver.sang@intel.com> wrote:
>
>
>
> Hello,
>
> kernel test robot noticed "BUG:KASAN:slab-out-of-bounds_in_fuse_evict_inode" on:
>
> commit: 6772e9ddfc996544d6a22e72eddf7510ac2999fc ("[PATCH v2] fuse: Track process write operations in both direct and writethrough modes")
> url: https://github.com/intel-lab-lkp/linux/commits/Zhou-Jifeng/fuse-Track-process-write-operations-in-both-direct-and-writethrough-modes/20231107-163300
> base: https://git.kernel.org/cgit/linux/kernel/git/mszeredi/fuse.git for-next
> patch link: https://lore.kernel.org/all/20231107081350.14472-1-zhoujifeng@kylinos.com.cn/
> patch subject: [PATCH v2] fuse: Track process write operations in both direct and writethrough modes
>
> in testcase: ltp
> version: ltp-x86_64-14c1f76-1_20230715
> with following parameters:
>
>         disk: 1HDD
>         fs: xfs
>         test: fs-03
>
>
>
> compiler: gcc-12
> test machine: 4 threads 1 sockets Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (Ivy Bridge) with 8G memory
>
> (please refer to attached dmesg/kmsg for entire log/backtrace)
>
>
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202311161627.5a936995-oliver.sang@intel.com
>
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20231116/202311161627.5a936995-oliver.sang@intel.com
>
>
> [  608.279527][ T5411] ==================================================================
> [  608.279697][ T5411] BUG: KASAN: slab-out-of-bounds in fuse_evict_inode+0x15c/0x4a0 [fuse]
> [  608.279871][ T5411] Write of size 4 at addr ffff888092af0dc8 by task fs_fill/5411
> [  608.280019][ T5411]
> [  608.280082][ T5411] CPU: 1 PID: 5411 Comm: fs_fill Not tainted 6.6.0-rc2-00004-g6772e9ddfc99 #1
> [  608.280252][ T5411] Hardware name: Hewlett-Packard p6-1451cx/2ADA, BIOS 8.15 02/05/2013
> [  608.280409][ T5411] Call Trace:
> [  608.280494][ T5411]  <TASK>
> [  608.280570][ T5411]  dump_stack_lvl+0x36/0x50
> [  608.280674][ T5411]  print_address_description+0x2c/0x3a0
> [  608.280808][ T5411]  ? fuse_evict_inode+0x15c/0x4a0 [fuse]
> [  608.280935][ T5411]  print_report+0xba/0x2b0
> [  608.281034][ T5411]  ? kasan_addr_to_slab+0xd/0x90
> [  608.281140][ T5411]  ? fuse_evict_inode+0x15c/0x4a0 [fuse]
> [  608.281266][ T5411]  kasan_report+0xc7/0x100
> [  608.281604][ T5411]  ? fuse_evict_inode+0x15c/0x4a0 [fuse]
> [  608.281763][ T5411]  kasan_check_range+0xfc/0x1a0
> [  608.281871][ T5411]  fuse_evict_inode+0x15c/0x4a0 [fuse]
> [  608.281994][ T5411]  evict+0x29b/0x5e0
> [  608.282086][ T5411]  ? lookup_one_qstr_excl+0x23/0x150
> [  608.282201][ T5411]  do_unlinkat+0x34f/0x5a0
> [  608.282300][ T5411]  ? __x64_sys_rmdir+0xf0/0xf0
> [  608.282404][ T5411]  ? 0xffffffff81000000
> [  608.282498][ T5411]  ? strncpy_from_user+0x6a/0x230
> [  608.282611][ T5411]  ? getname_flags+0x8d/0x430
> [  608.282724][ T5411]  __x64_sys_unlink+0xa9/0xf0
> [  608.282827][ T5411]  do_syscall_64+0x38/0x80
> [  608.282928][ T5411]  entry_SYSCALL_64_after_hwframe+0x5e/0xc8
> [  608.283052][ T5411] RIP: 0033:0x7f6ba18898a7
> [  608.283574][ T5411] Code: f0 ff ff 73 01 c3 48 8b 0d 56 85 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 57 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 29 85 0d 00 f7 d8 64 89 01 48
> [  608.283947][ T5411] RSP: 002b:00007f6ba178ae48 EFLAGS: 00000246 ORIG_RAX: 0000000000000057
> [  608.284142][ T5411] RAX: ffffffffffffffda RBX: 00007f6b94000b70 RCX: 00007f6ba18898a7
> [  608.284321][ T5411] RDX: 0000000000000000 RSI: 0000000000000039 RDI: 00007f6ba178ae90
> [  608.284503][ T5411] RBP: 00007f6ba178ae90 R08: 0000000000000000 R09: 0000000000000073
> [  608.284681][ T5411] R10: 0000000000000000 R11: 0000000000000246 R12: 0000562b20532004
> [  608.284862][ T5411] R13: 0000000000000039 R14: 0000000000000000 R15: 00007f6ba178ae90
> [  608.285050][ T5411]  </TASK>
> [  608.285150][ T5411]
> [  608.285237][ T5411] The buggy address belongs to the object at ffff888092af0b40
> [  608.285237][ T5411]  which belongs to the cache fuse_inode of size 824
> [  608.285514][ T5411] The buggy address is located 648 bytes inside of
> [  608.285514][ T5411]  allocated 824-byte region [ffff888092af0b40, ffff888092af0e78)
> [  608.285794][ T5411]
> [  608.285883][ T5411] The buggy address belongs to the physical page:
> [  608.286036][ T5411] page:00000000c8edd8aa refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x92af0
> [  608.286258][ T5411] head:00000000c8edd8aa order:2 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> [  608.286455][ T5411] memcg:ffff8881f087ff01
> [  608.286572][ T5411] flags: 0xfffffc0000840(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
> [  608.286753][ T5411] page_type: 0xffffffff()
> [  608.286867][ T5411] raw: 000fffffc0000840 ffff8881019c9e00 dead000000000122 0000000000000000
> [  608.287685][ T5411] raw: 0000000000000000 0000000080110011 00000001ffffffff ffff8881f087ff01
> [  608.287877][ T5411] page dumped because: kasan: bad access detected
> [  608.288035][ T5411]
> [  608.288121][ T5411] Memory state around the buggy address:
> [  608.288261][ T5411]  ffff888092af0c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [  608.288443][ T5411]  ffff888092af0d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [  608.288624][ T5411] >ffff888092af0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [  608.288803][ T5411]                                               ^
> [  608.288932][  T291] tst_fill_fs.c:126: TINFO: writev("mntpoint/subdir/thread4/AOF", iov, 512): ENOSPC
> [  608.288950][ T5411]  ffff888092af0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [  608.288953][ T5411]  ffff888092af0e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [  608.288984][  T291]
> [  608.289107][ T5411] ==================================================================
> [  608.289285][ T5411] Disabling lock debugging due to kernel taint
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
>

I carefully analyzed the patch I submitted, and I feel that the error in the ltp test has nothing to do with the "[PATCH v2] fuse: Track process write operations in both direct and writethrough modes" patch. Can you give me some guidance on the cause of the error?

Thanks,
Bernd
Krister Johansen Nov. 17, 2023, 5:15 p.m. UTC | #3 
On Fri, Nov 17, 2023 at 11:06:10AM +0800, 周继峰 wrote:
> Hi Miklos,
> 
> On Thu, Nov 16, 2023 at 4:43 PM kernel test robot <oliver.sang@intel.com> wrote:
> >
> >
> >
> > Hello,
> >
> > kernel test robot noticed "BUG:KASAN:slab-out-of-bounds_in_fuse_evict_inode" on:
> >
> > commit: 6772e9ddfc996544d6a22e72eddf7510ac2999fc ("[PATCH v2] fuse: Track process write operations in both direct and writethrough modes")
> > url: https://github.com/intel-lab-lkp/linux/commits/Zhou-Jifeng/fuse-Track-process-write-operations-in-both-direct-and-writethrough-modes/20231107-163300
> > base: https://git.kernel.org/cgit/linux/kernel/git/mszeredi/fuse.git for-next
> > patch link: https://lore.kernel.org/all/20231107081350.14472-1-zhoujifeng@kylinos.com.cn/
> > patch subject: [PATCH v2] fuse: Track process write operations in both direct and writethrough modes
> >
> > in testcase: ltp
> > version: ltp-x86_64-14c1f76-1_20230715
> > with following parameters:
> >
> >         disk: 1HDD
> >         fs: xfs
> >         test: fs-03
> >
> >
> >
> > compiler: gcc-12
> > test machine: 4 threads 1 sockets Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (Ivy Bridge) with 8G memory
> >
> > (please refer to attached dmesg/kmsg for entire log/backtrace)
> >
> >
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <oliver.sang@intel.com>
> > | Closes: https://lore.kernel.org/oe-lkp/202311161627.5a936995-oliver.sang@intel.com
> >
> >
> >
> > The kernel config and materials to reproduce are available at:
> > https://download.01.org/0day-ci/archive/20231116/202311161627.5a936995-oliver.sang@intel.com
> >
> >
> > [  608.279527][ T5411] ==================================================================
> > [  608.279697][ T5411] BUG: KASAN: slab-out-of-bounds in fuse_evict_inode+0x15c/0x4a0 [fuse]
> > [  608.279871][ T5411] Write of size 4 at addr ffff888092af0dc8 by task fs_fill/5411
> > [  608.280019][ T5411]
> > [  608.280082][ T5411] CPU: 1 PID: 5411 Comm: fs_fill Not tainted 6.6.0-rc2-00004-g6772e9ddfc99 #1
> > [  608.280252][ T5411] Hardware name: Hewlett-Packard p6-1451cx/2ADA, BIOS 8.15 02/05/2013
> > [  608.280409][ T5411] Call Trace:
> > [  608.280494][ T5411]  <TASK>
> > [  608.280570][ T5411]  dump_stack_lvl+0x36/0x50
> > [  608.280674][ T5411]  print_address_description+0x2c/0x3a0
> > [  608.280808][ T5411]  ? fuse_evict_inode+0x15c/0x4a0 [fuse]
> > [  608.280935][ T5411]  print_report+0xba/0x2b0
> > [  608.281034][ T5411]  ? kasan_addr_to_slab+0xd/0x90
> > [  608.281140][ T5411]  ? fuse_evict_inode+0x15c/0x4a0 [fuse]
> > [  608.281266][ T5411]  kasan_report+0xc7/0x100
> > [  608.281604][ T5411]  ? fuse_evict_inode+0x15c/0x4a0 [fuse]
> > [  608.281763][ T5411]  kasan_check_range+0xfc/0x1a0
> > [  608.281871][ T5411]  fuse_evict_inode+0x15c/0x4a0 [fuse]
> > [  608.281994][ T5411]  evict+0x29b/0x5e0
> > [  608.282086][ T5411]  ? lookup_one_qstr_excl+0x23/0x150
> > [  608.282201][ T5411]  do_unlinkat+0x34f/0x5a0
> > [  608.282300][ T5411]  ? __x64_sys_rmdir+0xf0/0xf0
> > [  608.282404][ T5411]  ? 0xffffffff81000000
> > [  608.282498][ T5411]  ? strncpy_from_user+0x6a/0x230
> > [  608.282611][ T5411]  ? getname_flags+0x8d/0x430
> > [  608.282724][ T5411]  __x64_sys_unlink+0xa9/0xf0
> > [  608.282827][ T5411]  do_syscall_64+0x38/0x80
> > [  608.282928][ T5411]  entry_SYSCALL_64_after_hwframe+0x5e/0xc8
> > [  608.283052][ T5411] RIP: 0033:0x7f6ba18898a7
> > [  608.283574][ T5411] Code: f0 ff ff 73 01 c3 48 8b 0d 56 85 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 57 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 29 85 0d 00 f7 d8 64 89 01 48
> > [  608.283947][ T5411] RSP: 002b:00007f6ba178ae48 EFLAGS: 00000246 ORIG_RAX: 0000000000000057
> > [  608.284142][ T5411] RAX: ffffffffffffffda RBX: 00007f6b94000b70 RCX: 00007f6ba18898a7
> > [  608.284321][ T5411] RDX: 0000000000000000 RSI: 0000000000000039 RDI: 00007f6ba178ae90
> > [  608.284503][ T5411] RBP: 00007f6ba178ae90 R08: 0000000000000000 R09: 0000000000000073
> > [  608.284681][ T5411] R10: 0000000000000000 R11: 0000000000000246 R12: 0000562b20532004
> > [  608.284862][ T5411] R13: 0000000000000039 R14: 0000000000000000 R15: 00007f6ba178ae90
> > [  608.285050][ T5411]  </TASK>
> > [  608.285150][ T5411]
> > [  608.285237][ T5411] The buggy address belongs to the object at ffff888092af0b40
> > [  608.285237][ T5411]  which belongs to the cache fuse_inode of size 824
> > [  608.285514][ T5411] The buggy address is located 648 bytes inside of
> > [  608.285514][ T5411]  allocated 824-byte region [ffff888092af0b40, ffff888092af0e78)
> > [  608.285794][ T5411]
> > [  608.285883][ T5411] The buggy address belongs to the physical page:
> > [  608.286036][ T5411] page:00000000c8edd8aa refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x92af0
> > [  608.286258][ T5411] head:00000000c8edd8aa order:2 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> > [  608.286455][ T5411] memcg:ffff8881f087ff01
> > [  608.286572][ T5411] flags: 0xfffffc0000840(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
> > [  608.286753][ T5411] page_type: 0xffffffff()
> > [  608.286867][ T5411] raw: 000fffffc0000840 ffff8881019c9e00 dead000000000122 0000000000000000
> > [  608.287685][ T5411] raw: 0000000000000000 0000000080110011 00000001ffffffff ffff8881f087ff01
> > [  608.287877][ T5411] page dumped because: kasan: bad access detected
> > [  608.288035][ T5411]
> > [  608.288121][ T5411] Memory state around the buggy address:
> > [  608.288261][ T5411]  ffff888092af0c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [  608.288443][ T5411]  ffff888092af0d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [  608.288624][ T5411] >ffff888092af0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [  608.288803][ T5411]                                               ^
> > [  608.288932][  T291] tst_fill_fs.c:126: TINFO: writev("mntpoint/subdir/thread4/AOF", iov, 512): ENOSPC
> > [  608.288950][ T5411]  ffff888092af0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [  608.288953][ T5411]  ffff888092af0e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [  608.288984][  T291]
> > [  608.289107][ T5411] ==================================================================
> > [  608.289285][ T5411] Disabling lock debugging due to kernel taint
> >
> > --
> > 0-DAY CI Kernel Test Service
> > https://github.com/intel/lkp-tests/wiki
> >
> >
> 
> I carefully analyzed the patch I submitted, and I feel that the error in the ltp test has nothing to do with the "[PATCH v2] fuse: Track process write operations in both direct and writethrough modes" patch. Can you give me some guidance on the cause of the error?

This looks like another incidence of a bug in a patch I sent to Miklos.
The fix for that was applied to fuse/for-next on 2023-11-10.  Looking
through the test logs attached to the report, it seems the robot used a
build from 11-08 which predates the fix.  If there's a way to instruct
the robot to re-run the test against the latest head of fuse/for-next,
I'd expect this to resolve.

-K
Miklos Szeredi March 5, 2024, 4:04 p.m. UTC | #4 
On Tue, 7 Nov 2023 at 09:14, Zhou Jifeng <zhoujifeng@kylinos.com.cn> wrote:
>
> Due to the fact that fuse does not count the write IO of processes in the
> direct and writethrough write modes, user processes cannot track
> write_bytes through the “/proc/[pid]/io” path. For example, the system
> tool iotop cannot count the write operations of the corresponding process.
>
> Signed-off-by: Zhou Jifeng <zhoujifeng@kylinos.com.cn>

Applied, thanks.

Miklos
diff mbox series

Patch

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 1cdb6327511e..4846ab8c01cf 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -19,6 +19,7 @@ 
 #include <linux/uio.h>
 #include <linux/fs.h>
 #include <linux/filelock.h>
+#include <linux/task_io_accounting_ops.h>
 
 static int fuse_send_open(struct fuse_mount *fm, u64 nodeid,
 			  unsigned int open_flags, int opcode,
@@ -1305,6 +1306,7 @@  static ssize_t fuse_cache_write_iter(struct kiocb *iocb, struct iov_iter *from)
 	ssize_t written = 0;
 	struct inode *inode = mapping->host;
 	ssize_t err;
+	ssize_t count;
 	struct fuse_conn *fc = get_fuse_conn(inode);
 
 	if (fc->writeback_cache) {
@@ -1330,6 +1332,9 @@  static ssize_t fuse_cache_write_iter(struct kiocb *iocb, struct iov_iter *from)
 	if (err <= 0)
 		goto out;
 
+	count = err;
+	task_io_account_write(count);
+
 	err = file_remove_privs(file);
 	if (err)
 		goto out;
@@ -1600,6 +1605,7 @@  static ssize_t fuse_direct_write_iter(struct kiocb *iocb, struct iov_iter *from)
 
 	res = generic_write_checks(iocb, from);
 	if (res > 0) {
+		task_io_account_write(res);
 		if (!is_sync_kiocb(iocb) && iocb->ki_flags & IOCB_DIRECT) {
 			res = fuse_direct_IO(iocb, from);
 		} else {