Re: panic: vm_domainset_iter_first: Unknown policy 15168
Date: Tue, 20 Jul 2021 17:13:20 UTC
On Tue, Jul 20, 2021 at 12:15:58PM -0400, Mark Johnston wrote: > On Tue, Jul 20, 2021 at 09:07:04AM -0700, Steve Kargl wrote: > > On Mon, Jul 19, 2021 at 07:05:03PM -0700, Steve Kargl wrote: > > > On Mon, Jul 19, 2021 at 07:55:07PM -0400, Mark Johnston wrote: > > > > On Mon, Jul 19, 2021 at 03:02:19PM -0700, Steve Kargl wrote: > > > > > > > > > > (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > > > > > #1 doadump (textdump=textdump@entry=1) > > > > > at /usr/src/sys/kern/kern_shutdown.c:399 > > > > > #2 0xffffffff805fe263 in kern_reboot (howto=260) > > > > > at /usr/src/sys/kern/kern_shutdown.c:486 > > > > > #3 0xffffffff805fe6b0 in vpanic (fmt=<optimized out>, ap=<optimized out>) > > > > > at /usr/src/sys/kern/kern_shutdown.c:919 > > > > > #4 0xffffffff805fe4b3 in panic (fmt=<unavailable>) > > > > > at /usr/src/sys/kern/kern_shutdown.c:843 > > > > > #5 0xffffffff8085dcbb in vm_domainset_iter_first (di=<optimized out>, > > > > > domain=<optimized out>) at /usr/src/sys/vm/vm_domainset.c:189 > > > > > #6 0xffffffff8085dbd2 in vm_domainset_iter_page_init ( > > > > > di=di@entry=0xfffffe012ae5e2a0, obj=obj@entry=0xfffff8003c21f420, > > > > > pindex=<optimized out>, pindex@entry=16931, > > > > > domain=domain@entry=0xfffffe012ae5e2f4, req=<unavailable>, > > > > > req@entry=0xfffffe012ae5e2f0) at /usr/src/sys/vm/vm_domainset.c:217 > > > > > > > > Could you please show output from: > > > > > > > > (kgdb) frame 6 > > > > (kgdb) p *dr > > > > (kgdb) p obj->domain > > > > > > > > > > The system is at work. I'll do this tomorrow morning. > > > Thanks for asking for additional info. > > > > > > > Hi Mark, I poked around and tried to supply the request info > > along with content of other structs. > > > > (kgdb) frame 6 > > #6 0xffffffff8085dbd2 in vm_domainset_iter_page_init ( > > di=di@entry=0xfffffe012ae5e2a0, obj=obj@entry=0xfffff8003c21f420, > > pindex=<optimized out>, pindex@entry=16931, > > domain=domain@entry=0xfffffe012ae5e2f4, req=<unavailable>, > > req@entry=0xfffffe012ae5e2f0) at /usr/src/sys/vm/vm_domainset.c:217 > > 217 vm_domainset_iter_first(di, domain); > > (kgdb) p *dr > > value has been optimized out > > (kgdb) p obj->domain > > $1 = {dr_policy = 0xfffff800064b9c60, dr_iter = 0} > > (kgdb) p *obj->domain->dr_policy > > $3 = {ds_link = {le_next = 0xfffff8003c21f420, le_prev = 0xfffffe000ce71188}, > > ds_mask = {__bits = {0}}, ds_policy = 15168, ds_prefer = 231 '\347', > > ds_cnt = 12 '\f', > > ds_order = "\000\376\377\377@", <incomplete sequence \347\014>} > > (kgdb) p *di > > $8 = {di_domain = 0xfffff800064b9c60, di_iter = 0xfffff8003c21f490, > > di_offset = 35190825029656, di_flags = 86066, di_policy = 15168, > > di_n = 255 '\377', di_minskip = true} > > So the object somehow ended up referencing a bogus domainset. Could you > please also show > > (kgdb) p *obj > (kgdb) p vnode_domainset > (kgdb) p *obj $1 = {lock = {lock_object = {lo_name = 0xffffffff8092d720 "vm object", lo_flags = 627245056, lo_data = 0, lo_witness = 0x0}, rw_lock = 18446741878362575616}, object_list = { tqe_next = 0xfffff8003c21f528, tqe_prev = 0xfffff8003c21f338}, shadow_head = {lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0x0}, memq = {tqh_first = 0xfffffe000d44b290, tqh_last = 0xfffffe000d418a30}, rtree = {rt_root = 18446735285712745888}, size = 527600, domain = {dr_policy = 0xfffff800064b9c60, dr_iter = 0}, generation = 1, cleangeneration = 1, ref_count = 0, shadow_count = 0, memattr = 6 '\006', type = 2 '\002', flags = 0, pg_color = 0, paging_in_progress = {__count = 0}, busy = {__count = 0}, resident_page_count = 5383, backing_object = 0x0, backing_object_offset = 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = { lh_first = 0x0}, handle = 0xfffff801e23d3380, un_pager = {vnp = { vnp_size = 2161049600, writemappings = 0}, devp = {devp_pglist = { tqh_first = 0x80cf0000, tqh_last = 0x0}, ops = 0x0, dev = 0x0}, sgp = { sgp_pglist = {tqh_first = 0x80cf0000, tqh_last = 0x0}}, swp = { swp_tmpfs = 0x80cf0000, swp_blks = {pt_root = 0}, writemappings = 0}, phys = {ops = 0x80cf0000, {data_ptr = 0x0, data_val = 0}}}, cred = 0x0, charge = 0, umtx_data = 0x0} (kgdb) p vnode_domainset $2 = (struct domainset *) 0x0 > > Is the problem reproducible? Don't know if it matters, but the DVD was prepared on a MS Windows 10 system. I don't know what software was used. I got 4 different panics while trying to copy data from the UDF disk. % mount_udf /dev/cd0 /cdrom This mounts the drive and I can ls and cd into it. If I do % cd ${HOME}/data <-- UFS2, softupdate % cp -R /cdrom/data . where /cdrom/data is a directory with 4000-ish files, I eventually get a panic. Two of the other panics are of the form (which may be a result of UDF handing FFS bad data). KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00db4045e0 vpanic() at vpanic+0x181/frame 0xfffffe00db404630 panic() at panic+0x43/frame 0xfffffe00db404690 trap_fatal() at trap_fatal+0x381/frame 0xfffffe00db4046f0 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00db404750 trap() at trap+0x27d/frame 0xfffffe00db404860 calltrap() at calltrap+0x8/frame 0xfffffe00db404860 --- trap 0xc, rip = 0x25630000, rsp = 0xfffffe00db404938, rbp = 0xfffffe00db4049c0 --- kernload() at 0x25630000/frame 0xfffffe00db4049c0 ffs_syncvnode() at ffs_syncvnode+0x347/frame 0xfffffe00db404a50 ffs_fsync() at ffs_fsync+0x22/frame 0xfffffe00db404a90 sched_sync() at sched_sync+0x3e2/frame 0xfffffe00db404b30 fork_exit() at fork_exit+0x71/frame 0xfffffe00db404b70 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00db404b70 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=textdump@entry=1) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff805fe263 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:486 #3 0xffffffff805fe6b0 in vpanic (fmt=<optimized out>, ap=<optimized out>) at /usr/src/sys/kern/kern_shutdown.c:919 #4 0xffffffff805fe4b3 in panic (fmt=<unavailable>) at /usr/src/sys/kern/kern_shutdown.c:843 #5 0xffffffff808e19b1 in trap_fatal (frame=0xfffffe00db404870, eva=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:915 #6 0xffffffff808e1a0f in trap_pfault (frame=frame@entry=0xfffffe00db404870, usermode=false, signo=<optimized out>, signo@entry=0x0, ucode=<optimized out>, ucode@entry=0x0) at /usr/src/sys/amd64/amd64/trap.c:732 #7 0xffffffff808e10cd in trap (frame=0xfffffe00db404870) at /usr/src/sys/amd64/amd64/trap.c:398 #8 <signal handler called> #9 0x0000000025630000 in ?? () #10 0xffffffff806a229c in bwrite (bp=0xfffffe001e26aec0) at /usr/src/sys/sys/buf.h:430 #11 vfs_bio_awrite (bp=<optimized out>, bp@entry=0xfffffe001e26aec0) at /usr/src/sys/kern/vfs_bio.c:3245 #12 0xffffffff8083fd67 in ffs_syncvnode (vp=vp@entry=0xfffff80112f4da80, waitfor=3, flags=flags@entry=0) at /usr/src/sys/ufs/ffs/ffs_vnops.c:378 #13 0xffffffff8083e9f2 in ffs_fsync (ap=0xfffffe00db404ab0) at /usr/src/sys/ufs/ffs/ffs_vnops.c:230 #14 0xffffffff806ca1a2 in VOP_FSYNC (vp=0xfffff80112f4da80, waitfor=3, td=0xfffffe00dae5a800) at ./vnode_if.h:771 #15 sync_vnode (slp=<optimized out>, bo=<optimized out>, td=0xfffffe00dae5a800) at /usr/src/sys/kern/vfs_subr.c:2617 #16 sched_sync () at /usr/src/sys/kern/vfs_subr.c:2719 #17 0xffffffff805c8d01 in fork_exit (callout=0xffffffff806c9dc0 <sched_sync>, arg=<optimized out>, frame=<optimized out>) at /usr/src/sys/kern/kern_fork.c:1083 -- Steve