lkml.org 
[lkml]   [2016]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] mm, page_alloc: Keep pcp count and list contents in sync if struct page is corrupted
On Fri, Dec 02, 2016 at 11:04:11AM +0100, Michal Hocko wrote:
> On Fri 02-12-16 17:30:07, Hillf Danton wrote:
> [...]
> > > >> @@ -2217,13 +2217,14 @@ static int rmqueue_bulk(struct zone *zone, unsigned int order,
> > > >> else
> > > >> list_add_tail(&page->lru, list);
> > > >> list = &page->lru;
> > > >> + alloced++;
> > > >> if (is_migrate_cma(get_pcppage_migratetype(page)))
> > > >> __mod_zone_page_state(zone, NR_FREE_CMA_PAGES,
> > > >> -(1 << order));
> > > >> }
> > > >> __mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));
> > > >
> > > > Now i is a pure index, yes?
> > >
> > > No, even if a page fails the check_pcp_refill() check and is not
> > > "allocated", it is also no longer a free page, so it's correct to
> > > subtract it from NR_FREE_PAGES.
> > >
> > Yes, we can allocate free page next time.
>
> No we cannot. The page is gone from the free list. We have effectively
> leaked it.

And deliberately so. It's in an unknown state, possibly due to memory
corruption or a use-after free bug. The machine can continue limping on
with warnings in the kernel log but the VM stops going near the page
itself as much as possible.

--
Mel Gorman
SUSE Labs

\
 
 \ /
  Last update: 2016-12-02 12:03    [W:0.122 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site