On Fri, Nov 09, 2018 at 05:03:06PM +0530, Anshuman Khandual wrote: > > > On 11/09/2018 12:17 PM, Naoya Horiguchi wrote: > > The new function is a reverse operation of set_hwpoison_free_buddy_page() > > to adjust unpoison_memory() to the new semantics. > > > > Signed-off-by: Naoya Horiguchi <n-horigu...@ah.jp.nec.com> > > snip > > > + > > +/* > > + * Reverse operation of set_hwpoison_free_buddy_page(), which is expected > > + * to work only on error pages isolated from buddy allocator. > > + */ > > +bool clear_hwpoison_free_buddy_page(struct page *page) > > +{ > > + struct zone *zone = page_zone(page); > > + bool unpoisoned = false; > > + > > + spin_lock(&zone->lock); > > + if (TestClearPageHWPoison(page)) { > > + unsigned long pfn = page_to_pfn(page); > > + int migratetype = get_pfnblock_migratetype(page, pfn); > > + > > + __free_one_page(page, pfn, zone, 0, migratetype); > > + unpoisoned = true; > > + } > > + spin_unlock(&zone->lock); > > + return unpoisoned; > > +} > > #endif > > > > Though there are multiple page state checks in unpoison_memory() leading > upto clearing HWPoison flag, the page must not be in buddy already if > __free_one_page() would be called on it.
Yes, you're right. clear_hwpoison_free_buddy_page() is intended to cancel the isolation by set_hwpoison_free_buddy_page() which removes the target page from buddy allocator, so the page clear_hwpoison_free_buddy_page() tries to handle is not a buddy page actually (not linked to any freelist). Thanks, Naoya Horiguchi