On Fri, Sep 27, 2019 at 2:59 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 27 Sep 2019 17:28:06 -0400 Qian Cai <cai@xxxxxx> wrote: > > > > > > > So I think you've moved the arch_free_page() to be after the final > > > thing which can access page contents, yes? If so, we should have a > > > comment in free_pages_prepare() to attmept to prevent this problem from > > > reoccurring as the code evolves? > > > > Right, something like this above arch_free_page() there? > > > > /* > > * It needs to be just above kernel_map_pages(), as s390 could mark those > > * pages unused and then trigger a fault when accessing. > > */ > > I did this. > > --- a/mm/page_alloc.c~mm-page_alloc-fix-a-crash-in-free_pages_prepare-fix > +++ a/mm/page_alloc.c > @@ -1179,7 +1179,13 @@ static __always_inline bool free_pages_p > kernel_init_free_pages(page, 1 << order); > > kernel_poison_pages(page, 1 << order, 0); > + /* > + * arch_free_page() can make the page's contents inaccessible. s390 > + * does this. So nothing which can access the page's contents should > + * happen after this. > + */ > arch_free_page(page, order); > + > if (debug_pagealloc_enabled()) > kernel_map_pages(page, 1 << order, 0); > So the question I would have is what is the state of the page after it has been marked unused and then pulled back in? I'm assuming it will be all 0s. I know with the work I am still doing on marking pages as unused this ends up being an additional item that we will need to pay attention to, however in our case we will just be initializing the page as zero if we end up evicting it from the guest.
