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 <[email protected]>
---
fs/fuse/file.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 1cdb6327511e..6051d2e2a021 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) {
@@ -1326,10 +1328,12 @@ static ssize_t fuse_cache_write_iter(struct kiocb *iocb, struct iov_iter *from)
writethrough:
inode_lock(inode);
- err = generic_write_checks(iocb, from);
- if (err <= 0)
+ count = generic_write_checks(iocb, from);
+ if (count <= 0)
goto out;
+ task_io_account_write(count);
+
err = file_remove_privs(file);
if (err)
goto out;
@@ -1600,6 +1604,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 {
--
2.18.1
Hi Zhou,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Zhou-Jifeng/fuse-Track-process-write-operations-in-both-direct-and-writethrough-modes/20231028-150119
base: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-next
patch link: https://lore.kernel.org/r/20231028065912.6084-1-zhoujifeng%40kylinos.com.cn
patch subject: [PATCH] fuse: Track process write operations in both direct and writethrough modes
config: x86_64-randconfig-161-20231103 (https://download.01.org/0day-ci/archive/20231107/[email protected]/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce: (https://download.01.org/0day-ci/archive/20231107/[email protected]/reproduce)
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 <[email protected]>
| Reported-by: Dan Carpenter <[email protected]>
| Closes: https://lore.kernel.org/r/[email protected]/
smatch warnings:
fs/fuse/file.c:1359 fuse_cache_write_iter() error: uninitialized symbol 'err'.
vim +/err +1359 fs/fuse/file.c
55752a3aba1387 Miklos Szeredi 2019-01-24 1302 static ssize_t fuse_cache_write_iter(struct kiocb *iocb, struct iov_iter *from)
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1303 {
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1304 struct file *file = iocb->ki_filp;
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1305 struct address_space *mapping = file->f_mapping;
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1306 ssize_t written = 0;
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1307 struct inode *inode = mapping->host;
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1308 ssize_t err;
56597c4ddc107c Zhou Jifeng 2023-10-28 1309 ssize_t count;
8981bdfda7445a Vivek Goyal 2020-10-09 1310 struct fuse_conn *fc = get_fuse_conn(inode);
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1311
8981bdfda7445a Vivek Goyal 2020-10-09 1312 if (fc->writeback_cache) {
4d99ff8f12eb20 Pavel Emelyanov 2013-10-10 1313 /* Update size (EOF optimization) and mode (SUID clearing) */
c6c745b81033a4 Miklos Szeredi 2021-10-22 1314 err = fuse_update_attributes(mapping->host, file,
c6c745b81033a4 Miklos Szeredi 2021-10-22 1315 STATX_SIZE | STATX_MODE);
4d99ff8f12eb20 Pavel Emelyanov 2013-10-10 1316 if (err)
4d99ff8f12eb20 Pavel Emelyanov 2013-10-10 1317 return err;
4d99ff8f12eb20 Pavel Emelyanov 2013-10-10 1318
8981bdfda7445a Vivek Goyal 2020-10-09 1319 if (fc->handle_killpriv_v2 &&
9452e93e6dae86 Christian Brauner 2023-01-13 1320 setattr_should_drop_suidgid(&nop_mnt_idmap,
9452e93e6dae86 Christian Brauner 2023-01-13 1321 file_inode(file))) {
8981bdfda7445a Vivek Goyal 2020-10-09 1322 goto writethrough;
8981bdfda7445a Vivek Goyal 2020-10-09 1323 }
8981bdfda7445a Vivek Goyal 2020-10-09 1324
84c3d55cc474f9 Al Viro 2014-04-03 1325 return generic_file_write_iter(iocb, from);
4d99ff8f12eb20 Pavel Emelyanov 2013-10-10 1326 }
4d99ff8f12eb20 Pavel Emelyanov 2013-10-10 1327
8981bdfda7445a Vivek Goyal 2020-10-09 1328 writethrough:
5955102c9984fa Al Viro 2016-01-22 1329 inode_lock(inode);
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1330
56597c4ddc107c Zhou Jifeng 2023-10-28 1331 count = generic_write_checks(iocb, from);
56597c4ddc107c Zhou Jifeng 2023-10-28 1332 if (count <= 0)
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1333 goto out;
Missing error code?
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1334
56597c4ddc107c Zhou Jifeng 2023-10-28 1335 task_io_account_write(count);
56597c4ddc107c Zhou Jifeng 2023-10-28 1336
5fa8e0a1c6a762 Jan Kara 2015-05-21 1337 err = file_remove_privs(file);
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1338 if (err)
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1339 goto out;
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1340
c3b2da31483449 Josef Bacik 2012-03-26 1341 err = file_update_time(file);
c3b2da31483449 Josef Bacik 2012-03-26 1342 if (err)
c3b2da31483449 Josef Bacik 2012-03-26 1343 goto out;
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1344
2ba48ce513c4e5 Al Viro 2015-04-09 1345 if (iocb->ki_flags & IOCB_DIRECT) {
1af5bb491fbb41 Christoph Hellwig 2016-04-07 1346 written = generic_file_direct_write(iocb, from);
84c3d55cc474f9 Al Viro 2014-04-03 1347 if (written < 0 || !iov_iter_count(from))
4273b793ec6875 Anand Avati 2012-02-17 1348 goto out;
64d1b4dd826d88 Christoph Hellwig 2023-06-01 1349 written = direct_write_fallback(iocb, from, written,
64d1b4dd826d88 Christoph Hellwig 2023-06-01 1350 fuse_perform_write(iocb, from));
4273b793ec6875 Anand Avati 2012-02-17 1351 } else {
596df33d673d9d Christoph Hellwig 2023-06-01 1352 written = fuse_perform_write(iocb, from);
4273b793ec6875 Anand Avati 2012-02-17 1353 }
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1354 out:
5955102c9984fa Al Viro 2016-01-22 1355 inode_unlock(inode);
e1c0eecba1a415 Miklos Szeredi 2017-09-12 1356 if (written > 0)
e1c0eecba1a415 Miklos Szeredi 2017-09-12 1357 written = generic_write_sync(iocb, written);
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1358
ea9b9907b82a09 Nicholas Piggin 2008-04-30 @1359 return written ? written : err;
ea9b9907b82a09 Nicholas Piggin 2008-04-30 1360 }
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
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 <[email protected]>
---
v1 -> v2: Fix "Miss error code" issue
fs/fuse/file.c | 6 ++++++
1 file changed, 6 insertions(+)
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 {
--
2.18.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/[email protected]/
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 <[email protected]>
| Closes: https://lore.kernel.org/oe-lkp/[email protected]
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20231116/[email protected]
[ 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
Hi Miklos,
On Thu, Nov 16, 2023 at 4:43 PM kernel test robot <[email protected]> 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/[email protected]/
> 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 <[email protected]>
> | Closes: https://lore.kernel.org/oe-lkp/[email protected]
>
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20231116/[email protected]
>
>
> [ 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
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 <[email protected]> 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/[email protected]/
> > 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 <[email protected]>
> > | Closes: https://lore.kernel.org/oe-lkp/[email protected]
> >
> >
> >
> > The kernel config and materials to reproduce are available at:
> > https://download.01.org/0day-ci/archive/20231116/[email protected]
> >
> >
> > [ 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
On Tue, 7 Nov 2023 at 09:14, Zhou Jifeng <[email protected]> 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 <[email protected]>
Applied, thanks.
Miklos