lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231117171543.GA2085@templeofstupid.com>
Date:   Fri, 17 Nov 2023 09:15:43 -0800
From:   Krister Johansen <kjlx@...pleofstupid.com>
To:     周继峰 <zhoujifeng@...inos.com.cn>
Cc:     kernel test robot <oliver.sang@...el.com>,
        oe-lkp <oe-lkp@...ts.linux.dev>, lkp <lkp@...el.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        ltp <ltp@...ts.linux.it>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        miklos <miklos@...redi.hu>
Subject: Re: [PATCH v2] fuse: Track process write operations in both direct
 and writethrough modes

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@...el.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@...el.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ