Date: Wed, 18 Dec 2024 17:58:04 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 283402] [fusefs] page fault when removing a fuse-backed CTL LUN mounted with atime Message-ID: <bug-283402-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283402 Bug ID: 283402 Summary: [fusefs] page fault when removing a fuse-backed CTL LUN mounted with atime 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 If you create a fuse mount that has default_permissions enabled but NOT noatime, then it is possible to trigger a page fault panic when removing a = CTL LUN backed by a file on this mountpoint. The reason is that kernel consume= rs like CTL don't have a ucred object. The same problem might happen with the= NFS server. I am not able to reproduce it using mdconfig to create a file-back= ed md device on top of fusefs. 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 # Note: atime MUST be enabled $ 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 $ sudo md5 /dev/da0 $ sudo ctladm remove -b block -l 0 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 0xfffffe00dc51d= 5e0 vpanic() at vpanic+0x136/frame 0xfffffe00dc51d710 panic() at panic+0x43/frame 0xfffffe00dc51d770 trap_fatal() at trap_fatal+0x40b/frame 0xfffffe00dc51d7d0 trap_pfault() at trap_pfault+0xa0/frame 0xfffffe00dc51d840 calltrap() at calltrap+0x8/frame 0xfffffe00dc51d840 --- trap 0xc, rip =3D 0xffffffff80c5db00, rsp =3D 0xfffffe00dc51d910, rbp = =3D 0xfffffe00dc51d940 --- vaccess() at vaccess+0x40/frame 0xfffffe00dc51d940 fuse_vnop_close() at fuse_vnop_close+0x1b3/frame 0xfffffe00dc51da40 VOP_CLOSE_APV() at VOP_CLOSE_APV+0x93/frame 0xfffffe00dc51da70 vn_close1() at vn_close1+0x139/frame 0xfffffe00dc51dae0 ctl_be_block_ioctl() at ctl_be_block_ioctl+0x84c/frame 0xfffffe00dc51db70 ctl_ioctl() at ctl_ioctl+0x15fc/frame 0xfffffe00dc51dbd0 devfs_ioctl() at devfs_ioctl+0xd1/frame 0xfffffe00dc51dc20 VOP_IOCTL_APV() at VOP_IOCTL_APV+0x96/frame 0xfffffe00dc51dc50 vn_ioctl() at vn_ioctl+0x160/frame 0xfffffe00dc51dcc0 devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe00dc51dce0 kern_ioctl() at kern_ioctl+0x286/frame 0xfffffe00dc51dd40 sys_ioctl() at sys_ioctl+0x12f/frame 0xfffffe00dc51de00 amd64_syscall() at amd64_syscall+0x1af/frame 0xfffffe00dc51df30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00dc51df30 --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x16fd98c1dc1a, rsp =3D 0x16fd93fc4768, rbp =3D 0x16fd93fc4930 --- KDB: enter: panic --=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-283402-227>