lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 12 Aug 2021 17:21:00 -0700
From:   Doug Berger <opendmb@...il.com>
To:     Vlastimil Babka <vbabka@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Mel Gorman <mgorman@...hsingularity.net>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/page_alloc: don't corrupt pcppage_migratetype

On 8/12/2021 1:17 AM, Vlastimil Babka wrote:
> On 8/11/21 8:29 PM, Doug Berger wrote:
>> When placing pages on a pcp list, migratetype values over
>> MIGRATE_PCPTYPES get added to the MIGRATE_MOVABLE pcp list.
>>
>> However, the actual migratetype is preserved in the page and
>> should not be changed to MIGRATE_MOVABLE or the page may end
>> up on the wrong free_list.
> 
> Nice, how did you find out? Were there any user-visible effects? (Hint: which?
> the changelog should say that so that the severity of the bug can be judged).
> Otherwise I agree the bug is there and patch is fixing it. Thanks.

I did not observe the bug "in the wild", but rather noticed it while
reviewing the current CMA implementation. I would imagine in the worst
case that CMA memory could leak onto MIGRATE_MOVABLE free_lists and get
"stolen" through fallback for MIGRATE_UNMOVABLE allocations effectively
breaking CMA.

For full disclosure I should take this opportunity to say that I am
investigating ways to improve the CMA/Movable memory implementations
somewhat in line with what Joonsoo Kim has been trying, which is why I
observed this bug.

However, I largely agree with the proposal Mel Gorman made in his
comments on:
https://lkml.org/lkml/2016/4/28/244

I can appreciate that zones may provide a convenient way of grouping
memory with common attributes, but it is a bastardization of the
original intention of zones. I would prefer a mechanism for designating
blocks of memory as "sticky" movable such that they can only be used to
satisfy movable memory requests and not be converted to other
migratetypes. I've wrestled with the terminology and currently favor
Designated Movable Blocks (as opposed to "sticky") because these are
blocks of memory that have the movable attribute by designation rather
than by default or accident.

While CMA blocks should be a subset of Designated Movable Blocks since
they have the same migration properties, it may be desirable/necessary
to maintain a distinction to accommodate competing allocation
objectives. Specifically, Designated Movable Blocks used by CMA to
satisfy the needs of drivers will likely want the page allocator to be
less aggressive than users of Memory Hot-plug or kernelcore= Designated
Movable Blocks. Perhaps a round-robin scheme with MIGRATE_MOVABLE can
satisfy all users, but I'm not too optimistic.

I don't know if Mel has changed his opinions on this matter, but any
suggestions and encouragement are appreciated.

Thanks,
    Doug

> 
>> Fixes: df1acc856923 ("mm/page_alloc: avoid conflating IRQs disabled with zone->lock")
>> Signed-off-by: Doug Berger <opendmb@...il.com>
> 
> Acked-by: Vlastimil Babka <vbabka@...e.cz>
> 
>> ---
>>  mm/page_alloc.c | 25 ++++++++++++-------------
>>  1 file changed, 12 insertions(+), 13 deletions(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 73704e836649..8addb4919f75 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -3436,19 +3436,10 @@ void free_unref_page_list(struct list_head *list)
>>  		 * comment in free_unref_page.
>>  		 */
>>  		migratetype = get_pcppage_migratetype(page);
>> -		if (unlikely(migratetype >= MIGRATE_PCPTYPES)) {
>> -			if (unlikely(is_migrate_isolate(migratetype))) {
>> -				list_del(&page->lru);
>> -				free_one_page(page_zone(page), page, pfn, 0,
>> -							migratetype, FPI_NONE);
>> -				continue;
>> -			}
>> -
>> -			/*
>> -			 * Non-isolated types over MIGRATE_PCPTYPES get added
>> -			 * to the MIGRATE_MOVABLE pcp list.
>> -			 */
>> -			set_pcppage_migratetype(page, MIGRATE_MOVABLE);
>> +		if (unlikely(is_migrate_isolate(migratetype))) {
>> +			list_del(&page->lru);
>> +			free_one_page(page_zone(page), page, pfn, 0, migratetype, FPI_NONE);
>> +			continue;
>>  		}
>>  
>>  		set_page_private(page, pfn);
>> @@ -3458,7 +3449,15 @@ void free_unref_page_list(struct list_head *list)
>>  	list_for_each_entry_safe(page, next, list, lru) {
>>  		pfn = page_private(page);
>>  		set_page_private(page, 0);
>> +
>> +		/*
>> +		 * Non-isolated types over MIGRATE_PCPTYPES get added
>> +		 * to the MIGRATE_MOVABLE pcp list.
>> +		 */
>>  		migratetype = get_pcppage_migratetype(page);
>> +		if (unlikely(migratetype >= MIGRATE_PCPTYPES))
>> +			migratetype = MIGRATE_MOVABLE;
>> +
>>  		trace_mm_page_free_batched(page);
>>  		free_unref_page_commit(page, pfn, migratetype, 0);
>>  
>>
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ