Re: panic: vm_domainset_iter_first: Unknown policy 15168

From: Steve Kargl <sgk_at_troutmask.apl.washington.edu>
Date: Tue, 20 Jul 2021 10:13:20 -0700
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_at_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_at_entry=0xfffffe012ae5e2a0, obj=obj_at_entry=0xfffff8003c21f420, 
> > > > >     pindex=<optimized out>, pindex_at_entry=16931, 
> > > > >     domain=domain_at_entry=0xfffffe012ae5e2f4, req=<unavailable>, 
> > > > >     req_at_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_at_entry=0xfffffe012ae5e2a0, obj=obj_at_entry=0xfffff8003c21f420, 
> >     pindex=<optimized out>, pindex_at_entry=16931, 
> >     domain=domain_at_entry=0xfffffe012ae5e2f4, req=<unavailable>, 
> >     req_at_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_at_", <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_at_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_at_entry=0xfffffe00db404870, 
    usermode=false, signo=<optimized out>, signo_at_entry=0x0, 
    ucode=<optimized out>, ucode_at_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_at_entry=0xfffffe001e26aec0)
    at /usr/src/sys/kern/vfs_bio.c:3245
#12 0xffffffff8083fd67 in ffs_syncvnode (vp=vp_at_entry=0xfffff80112f4da80, 
    waitfor=3, flags=flags_at_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
Received on Tue Jul 20 2021 - 17:13:20 UTC

Original text of this message