Re: panic: vm_page_free_prep: freeing mapped page

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Sun, 14 Jul 2019 23:03:54 +0300
On Sun, Jul 14, 2019 at 03:34:20PM -0400, Mark Johnston wrote:
> 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, 
The eflags value is slightly strange.

>   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
What is the object type ?  Can you please print the object(s) ?

> 
> 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?
Received on Sun Jul 14 2019 - 18:04:02 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC