svn commit: r226928 - head/sys/vm

[Alan Cox]

On 10/31/2011 11:33, Sergey Kandaurov wrote:
> On 30 October 2011 09:06, Alan Cox<alc at freebsd.org>  wrote:
>> Author: alc
>> Date: Sun Oct 30 05:06:14 2011
>> New Revision: 226928
>> URL: http://svn.freebsd.org/changeset/base/226928
>>
>> Log:
>>   Eliminate vm_phys_bootstrap_alloc().  It was a failed attempt at
>>   eliminating duplicated code in the various pmap implementations.
>>
>>   Micro-optimize vm_phys_free_pages().
>>
>>   Introduce vm_phys_free_contig().  It is fast routine for freeing an
>>   arbitrary number of physically contiguous pages.  In particular, it
>>   doesn't require the number of pages to be a power of two.
>>
>>   Use "u_long" instead of "unsigned long".
>>
>>   Bruce Evans (bde@) has convinced me that the "boundary" parameters
>>   to kmem_alloc_contig(), vm_phys_alloc_contig(), and
>>   vm_reserv_reclaim_contig() should be of type "vm_paddr_t" and not
>>   "u_long".  Make this change.
> Hello.
>
> After updating to this revision I constantly get random mtrash_ctor()
> assertions. [most often during make installkernel, otherwise idle.]
>
> Below is one of them (previous memory consumers in panicstr differ).
>
> Memory modified after free 0xfffffe0002700800(120) val=0 @ 0xfffffe0002700800
> panic: Most recently used by proc-args
>
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0xffffffff802e009a = db_trace_self_wrapper+0x2a
> kdb_backtrace() at 0xffffffff80486f17 = kdb_backtrace+0x37
> panic() at 0xffffffff8044f87e = panic+0x2ee
> mtrash_ctor() at 0xffffffff8068c904 = mtrash_ctor+0x84
> uma_zalloc_arg() at 0xffffffff8068c16c = uma_zalloc_arg+0x2dc
> malloc() at 0xffffffff8043abd6 = malloc+0xc6
> pargs_alloc() at 0xffffffff804425d3 = pargs_alloc+0x23
> kern_execve() at 0xffffffff8041cb47 = kern_execve+0x1277
> sys_execve() at 0xffffffff8041ce6d = sys_execve+0x3d
> amd64_syscall() at 0xffffffff806c6319 = amd64_syscall+0x299
> Xfast_syscall() at 0xffffffff806b16b7 = Xfast_syscall+0xf7
> --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800d4cbec, rsp =
> 0x7fffffffd1a8, rbp = 0x8014124a0 ---
>
>

I've not experienced anything like this, and I can't really see a direct 
connection between the above crash and the change.  So, the only thing 
that I can suggest is reverting one piece of the change at a time.  
Please try this first:

Index: vm/vm_phys.c
===================================================================
--- vm/vm_phys.c        (revision 226968)
+++ vm/vm_phys.c        (working copy)
@@ -758,7 +758,6 @@ vm_phys_alloc_contig(u_long npages, vm_paddr_t low
         struct vnode *vp;
         vm_paddr_t pa, pa_last, size;
         vm_page_t deferred_vdrop_list, m, m_ret;
-       u_long npages_end;
         int domain, flind, i, oind, order, pind;

  #if VM_NDOMAIN > 1
@@ -871,10 +870,13 @@ done:
                         deferred_vdrop_list = m;
                 }
         }
-       /* Return excess pages to the free lists. */
-       npages_end = roundup2(npages, 1 << imin(oind, order));
-       if (npages < npages_end)
-               vm_phys_free_contig(&m_ret[npages], npages_end - npages);
+       for (; i < roundup2(npages, 1 << imin(oind, order)); i++) {
+               m = &m_ret[i];
+               KASSERT(m->order == VM_NFREEORDER,
+                   ("vm_phys_alloc_contig: page %p has unexpected order 
%d",
+                   m, m->order));
+               vm_phys_free_pages(m, 0);
+       }
         mtx_unlock(&vm_page_queue_free_mtx);
         while (deferred_vdrop_list != NULL) {
                 vdrop((struct vnode *)deferred_vdrop_list->pageq.tqe_prev);