All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miaohe Lin <linmiaohe@huawei.com>
To: Vlastimil Babka <vbabka@suse.cz>, Matthew Wilcox <willy@infradead.org>
Cc: <akpm@linux-foundation.org>, <sfr@canb.auug.org.au>,
	<peterz@infradead.org>, <mgorman@techsingularity.net>,
	<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 6/6] mm/page_alloc.c: avoid allocating highmem pages via alloc_pages_exact_nid()
Date: Wed, 1 Sep 2021 16:05:44 +0800	[thread overview]
Message-ID: <d3cc4289-c62d-49d2-ef55-85f3e5c2e588@huawei.com> (raw)
In-Reply-To: <cde527a6-36cf-8a01-16b9-41e950676e48@suse.cz>

On 2021/9/1 0:37, Vlastimil Babka wrote:
> On 8/31/21 03:56, Miaohe Lin wrote:
>> On 2021/8/30 22:24, Matthew Wilcox wrote:
>>> On Mon, Aug 30, 2021 at 10:10:51PM +0800, Miaohe Lin wrote:
>>>> Don't use with __GFP_HIGHMEM because page_address() cannot represent
>>>> highmem pages without kmap(). Newly allocated pages would leak as
>>>> page_address() will return NULL for highmem pages here. But It works
>>>> now because the only caller does not specify __GFP_HIGHMEM now.
>>>
>>> This is a misunderstanding of how alloc_pages_exact() /
>>> alloc_pages_exact_nid() work.  You simply can't call them with
>>> GFP_HIGHMEM.
>>>
>>
>> Yep, they can't work with GFP_HIGHMEM. So IMO it might be better to
>> get rid of GFP_HIGHMEM explicitly or add a comment to clarify this
>> situation to avoid future misbehavior. But this may be a unnecessary
>> worry... Do you prefer to not change anything here?
> 
> I agree with the suggestion below...
> 
>> Many thanks.
>>
>>> If you really must change anything here,
>>> s/__GFP_COMP/(__GFP_COMP|__GFP_HIGHMEM)/g throughout both
>>> alloc_pages_exact() and alloc_pages_exact_nid().
> 
> ... which means __GFP_HIGHMEM would be stripped and additionally there would
> be a warning.
> 

Looks good for me. Will do. Many thanks!

> .
> 


      reply	other threads:[~2021-09-01  8:05 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30 14:10 [PATCH 0/6] Cleanups and fixup for page_alloc Miaohe Lin
2021-08-30 14:10 ` [PATCH 1/6] mm/page_alloc.c: remove meaningless VM_BUG_ON() in pindex_to_order() Miaohe Lin
2021-08-31 13:34   ` Mel Gorman
2021-08-31 14:05   ` David Hildenbrand
2021-08-30 14:10 ` [PATCH 2/6] mm/page_alloc.c: simplify the code by using macro K() Miaohe Lin
2021-08-31  8:54   ` Oleksandr Natalenko
2021-08-31 11:08     ` Miaohe Lin
2021-08-31 14:19       ` Oleksandr Natalenko
2021-09-01  7:37         ` Miaohe Lin
2021-09-01  7:46           ` Oleksandr Natalenko
2021-09-01  8:17             ` Miaohe Lin
2021-09-01 21:25           ` David Laight
2021-09-02  6:32             ` Miaohe Lin
2021-08-31 13:35   ` Mel Gorman
2021-08-31 14:07   ` David Hildenbrand
2021-08-30 14:10 ` [PATCH 3/6] mm/page_alloc.c: remove obsolete comment in free_pcppages_bulk() Miaohe Lin
2021-08-31 13:38   ` Mel Gorman
2021-09-01  7:49     ` Miaohe Lin
2021-09-01 15:14       ` Mel Gorman
2021-09-02  6:25         ` Miaohe Lin
2021-08-30 14:10 ` [PATCH 4/6] mm/page_alloc.c: use helper function zone_spans_pfn() Miaohe Lin
2021-08-31 13:39   ` Mel Gorman
2021-08-31 14:08   ` David Hildenbrand
2021-08-30 14:10 ` [PATCH 5/6] mm/page_alloc.c: avoid accessing uninitialized pcp page migratetype Miaohe Lin
2021-08-31 13:43   ` Mel Gorman
2021-08-31 14:23     ` David Hildenbrand
2021-09-01  8:02       ` Miaohe Lin
2021-09-01  8:10         ` David Hildenbrand
2021-09-01  8:18           ` Miaohe Lin
2021-08-31 16:34     ` Vlastimil Babka
2021-09-01  8:04       ` Miaohe Lin
2021-08-30 14:10 ` [PATCH 6/6] mm/page_alloc.c: avoid allocating highmem pages via alloc_pages_exact_nid() Miaohe Lin
2021-08-30 14:24   ` Matthew Wilcox
2021-08-31  1:56     ` Miaohe Lin
2021-08-31 16:37       ` Vlastimil Babka
2021-09-01  8:05         ` Miaohe Lin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d3cc4289-c62d-49d2-ef55-85f3e5c2e588@huawei.com \
    --to=linmiaohe@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=peterz@infradead.org \
    --cc=sfr@canb.auug.org.au \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.