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