lkml.org 
[lkml]   [2012]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[3.7-rc6] capture_free_page() frees page without accounting for them??
Hi Mel,

I'm chasing an apparent memory leak introduced post-3.6. The
interesting thing is that it appears that the pages are in the
allocator, but not being accounted for:

http://www.spinics.net/lists/linux-mm/msg46187.html
https://bugzilla.kernel.org/show_bug.cgi?id=50181

I started auditing anything that might be messing with NR_FREE_PAGES,
and came across commit 1fb3f8ca. It does something curious with
capture_free_page() (previously known as split_free_page()).

int capture_free_page(struct page *page, int alloc_order,
...
__mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order));

- /* Split into individual pages */
- set_page_refcounted(page);
- split_page(page, order);
+ if (alloc_order != order)
+ expand(zone, page, alloc_order, order,
+ &zone->free_area[order], migratetype);

Note that expand() puts the pages _back_ in the allocator, but it does
not bump NR_FREE_PAGES. We "return" alloc_order' worth of pages, but we
accounted for removing 'order'.

I _think_ the correct fix is to just:

- __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order));
+ __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << alloc_order));

I'm trying to confirm the theory my making this happen a bit more often,
but I'd appreciate a second pair of eyes on the code in case I'm reading
it wrong.



\
 
 \ /
  Last update: 2012-11-20 21:41    [W:0.041 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site