[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <38b32d77-8ab7-1971-63e4-0bd8c4c1d3da@de.ibm.com>
Date: Mon, 30 Sep 2019 08:30:25 +0200
From: Christian Borntraeger <borntraeger@...ibm.com>
To: Andrew Morton <akpm@...ux-foundation.org>, Qian Cai <cai@....pw>
Cc: heiko.carstens@...ibm.com, gor@...ux.ibm.com,
linux-s390@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/page_alloc: fix a crash in free_pages_prepare()
On 27.09.19 23:59, Andrew Morton wrote:
> On Fri, 27 Sep 2019 17:28:06 -0400 Qian Cai <cai@....pw> 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);
With that Acked-by: Christian Borntraeger <borntraeger@...ibm.com>
Powered by blists - more mailing lists