Re: panic: VM object not locked in vm_page_ps_test()

[Mark Johnston]

On Tue, Apr 17, 2018 at 10:03:55AM -0700, John Baldwin wrote:
> On Tuesday, April 17, 2018 10:01:41 AM John Baldwin wrote:
> > My laptop running recent head panicked this morning, apparently from hitting
> > a key to stop the screensaver (at which point xscreensaver prompts for a
> > password to unlock).
> 
> (Sorry, buggy mail client sent this early)
> 
> panic: Lock vm object not locked @ /usr/src/sys/vm/vm_page.c:4135
> 
> #4  0x805e4893 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:764
> #5  0x805dff22 in __rw_assert (c=, 
> what=, file=, line=)
> at /usr/src/sys/kern/kern_rwlock.c:1397
> #6  0x80882723 in vm_page_ps_test (m=0xf80431c2e980, flags=7, 
> skip_m=0xf80431c34890) at /usr/src/sys/vm/vm_page.c:4135
> #7  0x80867d84 in vm_fault_soft_fast (vaddr=, 
> prot=, fault_type=, 
> fault_flags=, wired=0, fs=, 
> m_hold=) at /usr/src/sys/vm/vm_fault.c:307
> #8  vm_fault_hold (map=0xf8000832a000, vaddr=, 
> fault_type=, fault_flags=, m_hold=0x0)
> at /usr/src/sys/vm/vm_fault.c:610
> #9  0x80866cf5 in vm_fault (map=0xf8000832a000, 
> vaddr=, fault_type=2 '\002', fault_flags=0)
> at /usr/src/sys/vm/vm_fault.c:514
> #10 0x808bc64c in trap_pfault (frame=0xfe008b1dbac0, usermode=1)
> at /usr/src/sys/amd64/amd64/trap.c:728
> #11 0x808bbe1e in trap (frame=0xfe008b1dbac0)
> #12 
> #13 0x000805b51556 in ?? ()
> 
> (kgdb) frame 6
> #6  0x80882723 in vm_page_ps_test (m=0xf80431c2e980, flags=7, 
> skip_m=0xf80431c34890) at /usr/src/sys/vm/vm_page.c:4135
> (kgdb) l
> 4130{
> 4131vm_object_t object;
> 4132int i, npages;
> 4133
> 4134object = m->object;
> 4135VM_OBJECT_ASSERT_LOCKED(object);
> 4136npages = atop(pagesizes[m->psind]);
> 4137
> 4138/*
> 4139 * The physically contiguous pages that make up a superpage, 
> i.e., a
> (kgdb) p m->object
> $1 = (vm_object_t) 0xf80190785900
> (kgdb) p pagesizes[m->psind]
> $3 = 2097152
> (kgdb) up
> #7  0x80867d84 in vm_fault_soft_fast (vaddr=, 
> prot=, fault_type=, 
> fault_flags=, wired=0, fs=, 
> m_hold=) at /usr/src/sys/vm/vm_fault.c:307
> 307 if (vm_page_ps_test(m_super, flags, m)) {
> (kgdb) p m->object
> $4 = (vm_object_t) 0xf80190116a00
> (kgdb) p/x m->flags
> $5 = 0x0
> 
> So 'm' (original page fault page) and 'm_super' are from different VM
> objects.  Why are they part of the same reservation?
> 
> (kgdb) p m->phys_addr >> (9 + 12)
> $7 = 4514
> (kgdb) p vm_reserv_array[$7]
> $8 = {lock = {lock_object = {lo_name = 0x8099112c "vm reserv", 
>   lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}, 
>   partpopq = {tqe_next = 0x0, tqe_prev = 0xf80423656680}, objq = {
> le_next = 0xf8042365b0c0, le_prev = 0xf80190116ab8}, 
>   object = 0xf80190116a00, pindex = 1760, pages = 0xf80431c2e980, 
>   domain = 0, popcnt = 512, inpartpopq = 0 '\000', popmap = {
> 18446744073709551615, 18446744073709551615, 18446744073709551615, 
> 18446744073709551615, 18446744073709551615, 18446744073709551615, 
> 18446744073709551615, 18446744073709551615}}
> (kgdb) set $rv = vm_reserv_array[$7]
> (kgdb) p $rv.object
> $9 = (vm_object_t) 0xf80190116a00
> 
> So rv->object matches m->object ($4) but not m_super->object ($1).
> Double-checking:
> 
> (kgdb) p m_super->object
> $10 = (vm_object_t) 0xf80190785900
> 
> Other conditions in vm_reserv_to_superpage() are true:
> 
> (kgdb) p $rv.pages
> $11 = (vm_page_t) 0xf80431c2e980
> (kgdb) p m_super
> $12 = (vm_page_t) 0xf80431c2e980
> (kgdb) p $rv.popcnt
> $13 = 512
> 
> Both objects are OBJT_DEFAULT objects:
> 
> (kgdb) p *m->object
> $14 = {lock = {lock_object = {lo_name = 0x8095e7ce "vm object", 
>   lo_flags = 627245056, lo_data = 0, lo_witness = 0x0}, rw_lock = 41}, 
>   object_list = {tqe_next = 0xf80190116b00, 
> tqe_prev = 0xf80190116920}, shadow_head = {lh_first = 0x0}, 
>   shadow_list = {le_next = 0x0, le_prev = 0xf80190785930}, memq = {
> tqh_first = 0xf80431ddf878, tqh_last = 0xf80431e2a900}, rtree = {
> rt_root = 18446735284333515328}, size = 2829, domain = {dr_policy = 0x0, 
> dr_iterator = 0}, generation = 1, ref_count = 3, shadow_count = 0, 
>   memattr = 6 '\006', type = 0 '\000', flags = 12352, pg_color = 1824, 
>   paging_in_progress = 1, resident_page_count = 1024, 
>   backing_object = 0xf80190785900, backing_object_offset = 0, 
>   pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {
> lh_first = 0xf80423659540}, handle = 0x0, un_pager = {vnp = {
>   vnp_size = 0, writemappings = 0}, devp = {devp_pglist = {
> tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, dev = 0x0}, sgp = {
>   sgp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_tmpfs = 
> 0x0, 
>   swp_blks = 

panic: VM object not locked in vm_page_ps_test()

[John Baldwin]

My laptop running recent head panicked this morning, apparently from hitting
a key to stop the screensaver (at which point xscreensaver prompts for a
password to unlock).


-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: VM object not locked in vm_page_ps_test()

[John Baldwin]

On Tuesday, April 17, 2018 10:01:41 AM John Baldwin wrote:
> My laptop running recent head panicked this morning, apparently from hitting
> a key to stop the screensaver (at which point xscreensaver prompts for a
> password to unlock).

(Sorry, buggy mail client sent this early)

panic: Lock vm object not locked @ /usr/src/sys/vm/vm_page.c:4135

#4  0x805e4893 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:764
#5  0x805dff22 in __rw_assert (c=, 
what=, file=, line=)
at /usr/src/sys/kern/kern_rwlock.c:1397
#6  0x80882723 in vm_page_ps_test (m=0xf80431c2e980, flags=7, 
skip_m=0xf80431c34890) at /usr/src/sys/vm/vm_page.c:4135
#7  0x80867d84 in vm_fault_soft_fast (vaddr=, 
prot=, fault_type=, 
fault_flags=, wired=0, fs=, 
m_hold=) at /usr/src/sys/vm/vm_fault.c:307
#8  vm_fault_hold (map=0xf8000832a000, vaddr=, 
fault_type=, fault_flags=, m_hold=0x0)
at /usr/src/sys/vm/vm_fault.c:610
#9  0x80866cf5 in vm_fault (map=0xf8000832a000, 
vaddr=, fault_type=2 '\002', fault_flags=0)
at /usr/src/sys/vm/vm_fault.c:514
#10 0x808bc64c in trap_pfault (frame=0xfe008b1dbac0, usermode=1)
at /usr/src/sys/amd64/amd64/trap.c:728
#11 0x808bbe1e in trap (frame=0xfe008b1dbac0)
#12 
#13 0x000805b51556 in ?? ()

(kgdb) frame 6
#6  0x80882723 in vm_page_ps_test (m=0xf80431c2e980, flags=7, 
skip_m=0xf80431c34890) at /usr/src/sys/vm/vm_page.c:4135
(kgdb) l
4130{
4131vm_object_t object;
4132int i, npages;
4133
4134object = m->object;
4135VM_OBJECT_ASSERT_LOCKED(object);
4136npages = atop(pagesizes[m->psind]);
4137
4138/*
4139 * The physically contiguous pages that make up a superpage, 
i.e., a
(kgdb) p m->object
$1 = (vm_object_t) 0xf80190785900
(kgdb) p pagesizes[m->psind]
$3 = 2097152
(kgdb) up
#7  0x80867d84 in vm_fault_soft_fast (vaddr=, 
prot=, fault_type=, 
fault_flags=, wired=0, fs=, 
m_hold=) at /usr/src/sys/vm/vm_fault.c:307
307 if (vm_page_ps_test(m_super, flags, m)) {
(kgdb) p m->object
$4 = (vm_object_t) 0xf80190116a00
(kgdb) p/x m->flags
$5 = 0x0

So 'm' (original page fault page) and 'm_super' are from different VM
objects.  Why are they part of the same reservation?

(kgdb) p m->phys_addr >> (9 + 12)
$7 = 4514
(kgdb) p vm_reserv_array[$7]
$8 = {lock = {lock_object = {lo_name = 0x8099112c "vm reserv", 
  lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}, 
  partpopq = {tqe_next = 0x0, tqe_prev = 0xf80423656680}, objq = {
le_next = 0xf8042365b0c0, le_prev = 0xf80190116ab8}, 
  object = 0xf80190116a00, pindex = 1760, pages = 0xf80431c2e980, 
  domain = 0, popcnt = 512, inpartpopq = 0 '\000', popmap = {
18446744073709551615, 18446744073709551615, 18446744073709551615, 
18446744073709551615, 18446744073709551615, 18446744073709551615, 
18446744073709551615, 18446744073709551615}}
(kgdb) set $rv = vm_reserv_array[$7]
(kgdb) p $rv.object
$9 = (vm_object_t) 0xf80190116a00

So rv->object matches m->object ($4) but not m_super->object ($1).
Double-checking:

(kgdb) p m_super->object
$10 = (vm_object_t) 0xf80190785900

Other conditions in vm_reserv_to_superpage() are true:

(kgdb) p $rv.pages
$11 = (vm_page_t) 0xf80431c2e980
(kgdb) p m_super
$12 = (vm_page_t) 0xf80431c2e980
(kgdb) p $rv.popcnt
$13 = 512

Both objects are OBJT_DEFAULT objects:

(kgdb) p *m->object
$14 = {lock = {lock_object = {lo_name = 0x8095e7ce "vm object", 
  lo_flags = 627245056, lo_data = 0, lo_witness = 0x0}, rw_lock = 41}, 
  object_list = {tqe_next = 0xf80190116b00, 
tqe_prev = 0xf80190116920}, shadow_head = {lh_first = 0x0}, 
  shadow_list = {le_next = 0x0, le_prev = 0xf80190785930}, memq = {
tqh_first = 0xf80431ddf878, tqh_last = 0xf80431e2a900}, rtree = {
rt_root = 18446735284333515328}, size = 2829, domain = {dr_policy = 0x0, 
dr_iterator = 0}, generation = 1, ref_count = 3, shadow_count = 0, 
  memattr = 6 '\006', type = 0 '\000', flags = 12352, pg_color = 1824, 
  paging_in_progress = 1, resident_page_count = 1024, 
  backing_object = 0xf80190785900, backing_object_offset = 0, 
  pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {
lh_first = 0xf80423659540}, handle = 0x0, un_pager = {vnp = {
  vnp_size = 0, writemappings = 0}, devp = {devp_pglist = {
tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0, dev = 0x0}, sgp = {
  sgp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_tmpfs = 0x0, 
  swp_blks = {pt_root = 0}}}, cred = 0xf80008d99500, 
  charge = 11587584, umtx_data = 0x0}
(kgdb) p *m_super->object
$15 = {lock = {lock_object = {lo_name = 0x8095e7ce "vm object", 
  lo_flags = 627245056, lo_data = 0, lo_witness = 0x0}, rw_lock = 1}, 
  object_list = {tqe_next =