[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 5/5] mm: Don't hold heap lock in alloc_heap_pages() longer than necessary
On Wed, Aug 30, 2017 at 08:59:34AM -0400, Boris Ostrovsky wrote: > > >> This patch has been applied to staging, but its got problems. The > >> following crash is rather trivial to provoke: > >> > >> ~Andrew > >> > >> (d19) Test result: SUCCESS > >> (XEN) ----[ Xen-4.10-unstable x86_64 debug=y Tainted: H ]---- > >> (XEN) CPU: 5 > >> (XEN) RIP: e008:[<ffff82d0802252fc>] > >> page_alloc.c#free_heap_pages+0x786/0x7a1 > >> ... > >> (XEN) Pagetable walk from ffff82ffffffffe4: > >> (XEN) L4[0x105] = 00000000abe5b063 ffffffffffffffff > >> (XEN) L3[0x1ff] = 0000000000000000 ffffffffffffffff > > Some negative offset into somewhere, it seems. Upon second > > look I think the patch is simply wrong in its current shape: > > free_heap_pages() looks for page_state_is(..., free) when > > trying to merge chunks, while alloc_heap_pages() now sets > > PGC_state_inuse outside of the locked area. I'll revert it right > > away. > > Yes, so we do need to update page state under heap lock. I'll then move > scrubbing (and checking) only to outside the lock. > > I am curious though, what was the test to trigger this? I ran about 100 > parallel reboots under memory pressure and never hit this. > Appears to be one of the tests in xtf.git _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |