Re: poisoned pages do not play well in the buddy allocator

[Michal Hocko]

On Fri 30-08-19 12:45:35, Oscar Salvador wrote:
> On Tue, Aug 27, 2019 at 09:28:13AM +0200, Oscar Salvador wrote:
> > On Tue, Aug 27, 2019 at 01:34:29AM +0000, Naoya Horiguchi wrote:
> > > > @Naoya: I could give it a try if you are busy.
> > > 
> > > Thanks for raising hand. That's really wonderful. I think that the series [1] is not
> > > merge yet but not rejected yet, so feel free to reuse/update/revamp it.
> > 
> > I will continue pursuing this then :-).
> 
> I have started implementing a fix for this.
> Right now I only performed tests on normal pages (non-hugetlb).
> 
> I took the approach of:
> 
> - Free page: remove it from the buddy allocator and set it as PageReserved|PageHWPoison.
> - Used page: migrate it and do not release it (skip put_page in unmap_and_move for MR_MEMORY_FAILURE
> 	     reason). Set it as PageReserved|PageHWPoison.

But this will only cover mapped pages. What about page cache in general?
Any reason why this cannot be handled in __free_one_page and simply skip
the whole freeing of the HWPoisoned parts of the freed page (in case of
higher order).

> The routine that handles this also sets the refcount of these pages to 1, so the unpoison
> machinery will only have to check for PageHWPoison and to a put_page() to send
> the page to the buddy allocator.
> 
> The Reserved bit is used because these pages will now __only__ be accessible through
> pfn walkers, and pfn walkers should respect Reserved pages.
> The PageHWPoison bit is used to remember that this page is poisoned, so the unpoison
> machinery knows that it is valid to unpoison it.

Do we really need both bits? pfn walkers in general shouldn't handle
pages they do not know about.

> It should also let us get rid of some if not all of the PageHWPoison() checks.

Although this sounds really appealing. The kernel code appart from the
hwpoison subsystem shouldn't really care about hwpoison status. With
some few isolated exceptions of course.
 
> Overall, it seems to work as I no longer see the issue our customer and I faced.

\o/

> My goal is to go further and publish that fix along with several
> cleanups/refactors for the soft-offline machinery (hard-poison will come later),
> as I strongly think we do really need to re-work that a bit, to make it more simple.
> 
> Since it will take a bit to have everything ready, I just wanted to
> let you know.

Thanks for the heads up and the work! The plan sounds great to me.
-- 
Michal Hocko
SUSE Labs