Date: Tue, 17 Dec 2024 20:26:44 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 283391] [fusefs] fuse_internal_cache_attrs: 0xfffff801e6e51898 is not exclusive locked but should be Message-ID: <bug-283391-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283391 Bug ID: 283391 Summary: [fusefs] fuse_internal_cache_attrs: 0xfffff801e6e51898 is not exclusive locked but should be Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: asomers@FreeBSD.org Incorrect locking in fusefs can lead to a panic, but only when DEBUG_VFS_LO= CKS is set in the kernel configuration. So far the only path I know that can trigger this panic is to come through CTL. Steps to Reproduce =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D $ pkg install -y fusefs-ext2 $ truncate -s 1g /tmp/ext2.img $ mkfs.ext2 /tmp/ext2.img $ sudo fuse-ext2 -o default_permissions,allow_other,rw+ /tmp/ext2.img /tmp/= mnt $ sudo truncate -s 1m /tmp/mnt/file $ sudo ctladm create -b block -o file=3D/tmp/mnt/file LUN created successfully backend: block device type: 0 LUN size: 1048576 bytes blocksize 512 bytes LUN ID: 0 Serial Number: MYSERIAL0000 Device ID: MYDEVID0000 $ sudo ctladm port -o on -p 0 That's usually enough to trigger the bug, but it may be necessary to read t= he resulting device file, too. Stack Trace =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00da0c4= a40 assert_vop_elocked() at assert_vop_elocked+0x56/frame 0xfffffe00da0c4a70 fuse_internal_cache_attrs() at fuse_internal_cache_attrs+0x47/frame 0xfffffe00da0c4ad0 fuse_internal_do_getattr() at fuse_internal_do_getattr+0x156/frame 0xfffffe00da0c4b80 fuse_vnode_size() at fuse_vnode_size+0x70/frame 0xfffffe00da0c4bd0 fuse_read_biobackend() at fuse_read_biobackend+0x56/frame 0xfffffe00da0c4c60 fuse_vnop_read() at fuse_vnop_read+0x12d/frame 0xfffffe00da0c4cc0 VOP_READ_APV() at VOP_READ_APV+0x96/frame 0xfffffe00da0c4cf0 ctl_be_block_dispatch_file() at ctl_be_block_dispatch_file+0x271/frame 0xfffffe00da0c4d90 ctl_be_block_worker() at ctl_be_block_worker+0xdab/frame 0xfffffe00da0c4e40 taskqueue_run_locked() at taskqueue_run_locked+0x1c2/frame 0xfffffe00da0c4e= c0 taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame 0xfffffe00da0c4= ef0 fork_exit() at fork_exit+0xc7/frame 0xfffffe00da0c4f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00da0c4f30 --- trap 0x2d0a6873, rip =3D 0x2038373030363372, rsp =3D 0x7720200a222f6461= , rbp =3D 0x617020200a303632 --- vnode 0xfffff80003af5528: type VREG state VSTATE_CONSTRUCTED op 0xffffffff82a23848 usecount 1, writecount 1, refcount 1 seqc users 0 hold count flags () flags (VMP_LAZYLIST) v_object 0xfffff80005d70e70 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type fuse: SHARED (count 1) nodeid: 3, parent nodeid: 0, nlookup: 2, flag: 0x2000 fuse_internal_cache_attrs: 0xfffff80003af5528 is not exclusive locked but should be KDB: enter: lock violation --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-283391-227>