[Bug 289131] [ZFS] [panic] zfs_aclset_common() with poolversion_test:poolversion_001_pos test
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 28 Aug 2025 08:55:41 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289131
Andriy Gapon <avg@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |Open
--- Comment #2 from Andriy Gapon <avg@FreeBSD.org> ---
I wonder if this is the same (very old) issue that I reported here:
https://mail-archive.freebsd.org/cgi/mid.cgi?d9f8b335-b180-9636-77a1-5bc430253314
Quoting for convenience:
Just a quick check before I dig into it.
Is this something that could have been fixed recently in OpenZFS?
Seems like a NULL pointer in zfs_mknode -> zfs_aclset_common.
fault virtual address = 0x4
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80370f2e
stack pointer = 0x28:0xfffffe01f24272a0
frame pointer = 0x28:0xfffffe01f2427450
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 27002 (zpool)
trap number = 12
panic: page fault
cpuid = 3
time = 1630470367
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff805c328b =
db_trace_self_wrapper+0x2b/frame
0xfffffe01f2426e60
kdb_backtrace() at 0xffffffff80889b17 = kdb_backtrace+0x37/frame
0xfffffe01f2426f10
vpanic() at 0xffffffff80846aa8 = vpanic+0x188/frame 0xfffffe01f2426f70
panic() at 0xffffffff808466c3 = panic+0x43/frame 0xfffffe01f2426fd0
trap_fatal() at 0xffffffff80b33905 = trap_fatal+0x375/frame 0xfffffe01f2427030
trap_pfault() at 0xffffffff80b339e0 = trap_pfault+0x80/frame 0xfffffe01f24270a0
trap() at 0xffffffff80b32fc1 = trap+0x271/frame 0xfffffe01f24271b0
trap_check() at 0xffffffff80b33d39 = trap_check+0x29/frame 0xfffffe01f24271d0
calltrap() at 0xffffffff80b0f3a8 = calltrap+0x8/frame 0xfffffe01f24271d0
--- trap 0xc, rip = 0xffffffff80370f2e, rsp = 0xfffffe01f24272a0, rbp =
0xfffffe01f2427450 ---
zfs_aclset_common() at 0xffffffff80370f2e = zfs_aclset_common+0x5e/frame
0xfffffe01f2427450
zfs_mknode() at 0xffffffff803894f3 = zfs_mknode+0xb43/frame 0xfffffe01f2427580
zfs_create_fs() at 0xffffffff8038cc60 = zfs_create_fs+0x590/frame
0xfffffe01f24276e0
dsl_pool_create() at 0xffffffff8041f6df = dsl_pool_create+0x2af/frame
0xfffffe01f2427740
spa_create() at 0xffffffff80450986 = spa_create+0x6f6/frame 0xfffffe01f2427800
zfs_ioc_pool_create() at 0xffffffff804c101b = zfs_ioc_pool_create+0x1fb/frame
0xfffffe01f2427880
zfsdev_ioctl_common() at 0xffffffff804bbea6 = zfsdev_ioctl_common+0x306/frame
0xfffffe01f2427900
zfsdev_ioctl() at 0xffffffff8036b49c = zfsdev_ioctl+0xfc/frame
0xfffffe01f2427940
devfs_ioctl() at 0xffffffff80718aef = devfs_ioctl+0xcf/frame 0xfffffe01f24279a0
VOP_IOCTL_APV() at 0xffffffff80bb5bd2 = VOP_IOCTL_APV+0x92/frame
0xfffffe01f24279c0
VOP_IOCTL() at 0xffffffff8092a6d4 = VOP_IOCTL+0x34/frame 0xfffffe01f2427a10
vn_ioctl() at 0xffffffff809259b0 = vn_ioctl+0xc0/frame 0xfffffe01f2427b00
devfs_ioctl_f() at 0xffffffff80718fde = devfs_ioctl_f+0x1e/frame
0xfffffe01f2427b20
fo_ioctl() at 0xffffffff808ae30b = fo_ioctl+0xb/frame 0xfffffe01f2427b30
kern_ioctl() at 0xffffffff808ae2a1 = kern_ioctl+0x1d1/frame 0xfffffe01f2427b80
sys_ioctl() at 0xffffffff808ae022 = sys_ioctl+0x132/frame 0xfffffe01f2427c50
syscallenter() at 0xffffffff80b34529 = syscallenter+0x159/frame
0xfffffe01f2427ca0
amd64_syscall() at 0xffffffff80b34205 = amd64_syscall+0x15/frame
0xfffffe01f2427d30
fast_syscall_common() at 0xffffffff80b0fcce = fast_syscall_common+0xf8/frame
0xfffffe01f2427d30
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004ca3ba, rsp =
0x7fffffffbb28, rbp = 0x7fffffffbb90 ---
The crash is in this piece of code:
1176 if (zp->z_zfsvfs->z_replay == B_FALSE) {
1177 ASSERT_VOP_IN_SEQC(ZTOV(zp));
1178 }
(kgdb) p zp->z_vnode
$2 = (vnode_t *) 0x0
It seems that this is to be expected when zfs_mknode is called with
IS_ROOT_NODE.
--
You are receiving this mail because:
You are the assignee for the bug.