From: Greg KH <greg@kroah.com>
To: Hailong Liu <hailong.liu@oppo.com>
Cc: stable@vger.kernel.org, Tangquan Zheng <zhengtangquan@oppo.com>,
Baoquan He <bhe@redhat.com>, Uladzislau Rezki <urezki@gmail.com>,
Barry Song <baohua@kernel.org>, Michal Hocko <mhocko@suse.com>,
Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 6.1.y] mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0
Date: Tue, 27 Aug 2024 14:38:07 +0200 [thread overview]
Message-ID: <2024082702-footer-comment-cb33@gregkh> (raw)
In-Reply-To: <20240820085242.18631-1-hailong.liu@oppo.com>
On Tue, Aug 20, 2024 at 04:52:42PM +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.
>
> Link: https://lkml.kernel.org/r/20240808122019.3361-1-hailong.liu@oppo.com
> 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>
> Reviewed-by: Baoquan He <bhe@redhat.com>
> Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> Acked-by: Barry Song <baohua@kernel.org>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> (cherry picked from commit 61ebe5a747da649057c37be1c37eb934b4af79ca)
> Signed-off-by: Hailong Liu <hailong.liu@oppo.com>
> ---
> mm/vmalloc.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index c5e30b52844c..a0b650f50faa 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2992,15 +2992,8 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
> page = alloc_pages(alloc_gfp, order);
> else
> page = alloc_pages_node(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
> --
> 2.25.1
>
>
Now queued up, thanks.
greg k-h
prev parent reply other threads:[~2024-08-27 12:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-19 9:54 FAILED: patch "[PATCH] mm/vmalloc: fix page mapping if vm_area_alloc_pages() with" failed to apply to 6.1-stable tree gregkh
2024-08-20 8:52 ` [PATCH 6.1.y] mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0 Hailong Liu
2024-08-27 12:38 ` Greg KH [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=2024082702-footer-comment-cb33@gregkh \
--to=greg@kroah.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=hailong.liu@oppo.com \
--cc=mhocko@suse.com \
--cc=stable@vger.kernel.org \
--cc=urezki@gmail.com \
--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.