From: Uladzislau Rezki <urezki@gmail.com>
To: Hailong Liu <hailong.liu@oppo.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Uladzislau Rezki <urezki@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
Tangquan Zheng <zhengtangquan@oppo.com>,
stable@vger.kernel.org, Barry Song <21cnbao@gmail.com>,
Baoquan He <bhe@redhat.com>, Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH v1] mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0
Date: Thu, 8 Aug 2024 16:57:49 +0200 [thread overview]
Message-ID: <ZrTc7SLz-f5E2SS4@pc636> (raw)
In-Reply-To: <20240808122019.3361-1-hailong.liu@oppo.com>
On Thu, Aug 08, 2024 at 08:19:56PM +0800, Hailong Liu wrote:
> The __vmap_pages_range_noflush() assumes its argument pages** contains
> pages with the same page shift. However, since commit e9c3cda4d86e
> ("mm, vmalloc: fix high order __GFP_NOFAIL allocations"), if gfp_flags
> includes __GFP_NOFAIL with high order in vm_area_alloc_pages()
> and page allocation failed for high order, the pages** may contain
> two different page shifts (high order and order-0). This could
> lead __vmap_pages_range_noflush() to perform incorrect mappings,
> potentially resulting in memory corruption.
>
> Users might encounter this as follows (vmap_allow_huge = true, 2M is for PMD_SIZE):
> kvmalloc(2M, __GFP_NOFAIL|GFP_X)
> __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP)
> vm_area_alloc_pages(order=9) ---> order-9 allocation failed and fallback to order-0
> vmap_pages_range()
> vmap_pages_range_noflush()
> __vmap_pages_range_noflush(page_shift = 21) ----> wrong mapping happens
>
> We can remove the fallback code because if a high-order
> allocation fails, __vmalloc_node_range_noprof() will retry with
> order-0. Therefore, it is unnecessary to fallback to order-0
> here. Therefore, fix this by removing the fallback code.
>
> Fixes: e9c3cda4d86e ("mm, vmalloc: fix high order __GFP_NOFAIL allocations")
> Signed-off-by: Hailong Liu <hailong.liu@oppo.com>
> Reported-by: Tangquan Zheng <zhengtangquan@oppo.com>
> Cc: <stable@vger.kernel.org>
> CC: Barry Song <21cnbao@gmail.com>
> CC: Baoquan He <bhe@redhat.com>
> CC: Matthew Wilcox <willy@infradead.org>
> ---
> mm/vmalloc.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 6b783baf12a1..af2de36549d6 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3584,15 +3584,8 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
> page = alloc_pages_noprof(alloc_gfp, order);
> else
> page = alloc_pages_node_noprof(nid, alloc_gfp, order);
> - if (unlikely(!page)) {
> - if (!nofail)
> - break;
> -
> - /* fall back to the zero order allocations */
> - alloc_gfp |= __GFP_NOFAIL;
> - order = 0;
> - continue;
> - }
> + if (unlikely(!page))
> + break;
>
> /*
> * Higher order allocations must be able to be treated as
> ---
> Sorry for fat fingers. with .rej file. resend this.
>
> Baoquan suggests set page_shift to 0 if fallback in (2 and concern about
> performance of retry with order-0. But IMO with retry,
> - Save memory usage if high order allocation failed.
> - Keep consistancy with align and page-shift.
> - make use of bulk allocator with order-0
>
> [2] https://lore.kernel.org/lkml/20240725035318.471-1-hailong.liu@oppo.com/
> --
> 2.30.0
>
Makes sense to me.
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Thank you!
--
Uladzislau Rezki
next prev parent reply other threads:[~2024-08-08 14:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-08 12:19 [RESEND PATCH v1] mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0 Hailong Liu
2024-08-08 13:01 ` Baoquan He
2024-08-08 14:57 ` Uladzislau Rezki [this message]
2024-08-08 21:05 ` Barry Song
2024-08-09 9:33 ` Michal Hocko
2024-08-09 9:41 ` Uladzislau Rezki
2024-08-16 5:07 ` Andrew Morton
2024-08-16 7:19 ` Uladzislau Rezki
2024-08-16 9:12 ` Hailong Liu
2024-08-16 10:13 ` Uladzislau Rezki
2024-08-16 11:46 ` Hailong Liu
2024-08-16 12:32 ` Michal Hocko
2024-08-23 16:42 ` Uladzislau Rezki
2024-08-26 7:52 ` Michal Hocko
2024-08-26 12:38 ` Uladzislau Rezki
2024-08-27 6:49 ` Michal Hocko
2024-08-27 12:47 ` Uladzislau Rezki
2024-08-27 13:37 ` Michal Hocko
2024-08-27 15:29 ` Uladzislau Rezki
2024-08-28 7:14 ` Michal Hocko
2024-08-28 17:23 ` Uladzislau Rezki
2024-08-19 11:59 ` Uladzislau Rezki
2024-08-19 12:57 ` Hailong Liu
2024-08-19 13:38 ` Uladzislau Rezki
2024-08-19 13:45 ` Uladzislau Rezki
2024-08-20 1:59 ` Hailong Liu
2024-08-20 6:44 ` Uladzislau Rezki
2024-08-20 6:54 ` Hailong Liu
2024-08-16 16:11 ` Baoquan He
2024-08-16 16:15 ` Baoquan He
-- strict thread matches above, loose matches on Subject: below --
2024-08-08 12:04 Hailong Liu
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=ZrTc7SLz-f5E2SS4@pc636 \
--to=urezki@gmail.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=hailong.liu@oppo.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=stable@vger.kernel.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=zhengtangquan@oppo.com \
/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.