Re: panic: vm_page_free_prep: freeing mapped page

On Sun, Jul 14, 2019 at 01:14:57AM +0300, Konstantin Belousov wrote:
> On Sat, Jul 13, 2019 at 04:50:57PM -0500, Larry Rosenman wrote:
> > I have cores.  Ideas?
> > svn rev: r349976
> > 
> > [I] ➜ more core.txt.12
> > borg.lerctr.org dumped core - see /var/crash/vmcore.12
> > 
> > Sat Jul 13 16:47:03 CDT 2019
> > 
> > FreeBSD borg.lerctr.org 13.0-CURRENT FreeBSD 13.0-CURRENT r349976 
> > LER-MINIMAL  amd64
> > 
> > panic: vm_page_free_prep: freeing mapped page 0xfffff82031044790
>
> What was the process which caused the panic ?  Was it threaded ?

I looked at some of the kernel dumps.  In all cases the crashing process
is postgres.  We have:

(kgdb) p/x *m->md.pv_list.tqh_first
$20 = {
  pv_va = 0x801c00000, 
  pv_next = {
    tqe_next = 0xfffff80b3aacb568, 
    tqe_prev = 0xfffff81faf7ecbe8
  }
}
(kgdb) p/x *m->md.pv_list.tqh_first->pv_next.tqe_next
$21 = {
  pv_va = 0x801c00000, 
  pv_next = {
    tqe_next = 0x0, 
    tqe_prev = 0xfffff80b3ab905d0
  }
}

We can find the corresponding pmaps for these mappings by going
through the corresponding pv_chunks.  Then I looked up the other
processes with mappings of the page.  They are also postgres processes.
We have:

$33 = {                
  prev = 0xfffff818baa2be00,      
  next = 0xfffff80e7e9875b0,     
  left = 0xfffff814df7a6310, 
  right = 0xfffff80e7e9875b0, 
  start = 0x801c00000,              
  end = 0x80aa4a000,              
  next_read = 0x801c00000, 
  max_free = 0x3000, 
  object = {                      
    vm_object = 0xfffff80bbeb94400, 
    sub_map = 0xfffff80bbeb94400
  },                              
  offset = 0x600000,      
  eflags = 0x0,                                                                        
  protection = 0x3,      
  max_protection = 0x7,    
  inheritance = 0x0,           
  read_ahead = 0xf,                                                                    
  wired_count = 0x0,                 
  cred = 0x0,                   
  wiring_thread = 0x0                    
}                  

and

(kgdb) p $33->object.vm_object->ref_count
$34 = 0
(kgdb) p $33->object.vm_object->shadow_count 
$35 = 5

So it seems that there is some problem with vm_object reference
counting; I'd expect a vm_map_entry reference to be counted in the
ref_count field, and we have at least two such references.

Larry, could you open a bugzilla PR for this panic?