All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Barry Song <21cnbao@gmail.com>, Hailong Liu <hailong.liu@oppo.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Uladzislau Rezki <urezki@gmail.com>,
	Christoph Hellwig <hch@infradead.org>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
	Matthew Wilcox <willy@infradead.org>,
	Tangquan Zheng <zhengtangquan@oppo.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2] mm/vmalloc: fix incorrect __vmap_pages_range_noflush() if vm_area_alloc_pages() from high order fallback to order0
Date: Mon, 29 Jul 2024 09:48:40 +0800	[thread overview]
Message-ID: <Zqb0+L/21/AKUagd@MiWiFi-R3L-srv> (raw)
In-Reply-To: <CAGsJ_4z0AYTVoCJjTyZsku24kPfOTnu1KCms_NPevdNKW+6sdg@mail.gmail.com>

Hi Barry,

On 07/26/24 at 03:53pm, Barry Song wrote:
> On Fri, Jul 26, 2024 at 2:31 PM Baoquan He <bhe@redhat.com> wrote:
......
> >  mm/mm_init.c <<alloc_large_system_hash>>
> >  table = vmalloc_huge(size, gfp_flags);
> >  net/ipv4/inet_hashtables.c <<inet_pernet_hashinfo_alloc>>
> >  new_hashinfo->ehash = vmalloc_huge(ehash_entries * sizeof(struct inet_ehash_bucket),
> >  net/ipv4/udp.c <<udp_pernet_table_alloc>>
> >  udptable->hash = vmalloc_huge(hash_entries * 2 * sizeof(struct udp_hslot)
> >
> > Maybe we should add code comment or document to notice people that the
> > contiguous physical pages are not guaranteed for vmalloc_huge() if you
> > use it after boot.
> 
> Currently, the issue goes beyond just 'contiguous physical pages are
> not guaranteed.'
> The problem includes the likelihood of failure when trying to allocate
> 2MB of contiguous
> memory. That's why I suggest we allow fallback to order-0 for
> non-nofail allocations with
> your proposed changes.

I missed this part of your comment, I agree with you. I think it's doable
with below draft patch combined with my earlier draft change.


diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 260897b21b11..9ae85342d337 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3581,11 +3581,11 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
 		else
 			page = alloc_pages_node_noprof(nid, alloc_gfp, order);
 		if (unlikely(!page)) {
-			if (!nofail)
+			if (!nofail && !order)
 				break;
 
 			/* fall back to the zero order allocations */
-			alloc_gfp |= __GFP_NOFAIL;
+			alloc_gfp = gfp;
 			order = 0;
 			continue;
 		}


Hi Hailong,

Please feel free to collect them to post formal patch, maybe two
patches, one is to allow non-nofail to fallback to order-0 in
vm_area_alloc_pages(), the other is passing out the fallbacked
page_order to vmap_pages_range() if it's OK.

Thanks
Baoquan



  reply	other threads:[~2024-07-29  1:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-25  3:53 [RFC PATCH v2] mm/vmalloc: fix incorrect __vmap_pages_range_noflush() if vm_area_alloc_pages() from high order fallback to order0 hailong.liu
2024-07-25  6:21 ` Barry Song
2024-07-25  9:17   ` Hailong Liu
2024-07-25  9:34     ` Barry Song
2024-07-25  9:58       ` Hailong Liu
2024-07-25 10:22         ` Barry Song
2024-07-25 11:39 ` Baoquan He
2024-07-25 16:40   ` Hailong Liu
2024-07-26  1:31     ` Barry Song
2024-07-26  2:31     ` Baoquan He
2024-07-26  3:53       ` Barry Song
2024-07-29  1:48         ` Baoquan He [this message]
2024-07-30  3:24           ` Hailong Liu
2024-07-30  4:29             ` Baoquan He
2024-07-26  4:00       ` Hailong Liu
2024-07-26  5:03         ` Hailong Liu
2024-07-26  5:29           ` Barry Song
2024-07-26  8:37             ` Baoquan He
2024-07-26  8:48               ` Hailong Liu
2024-07-26  9:00                 ` Hailong Liu
2024-07-26  9:29                 ` Baoquan He
2024-07-26  9:15               ` Barry Song

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=Zqb0+L/21/AKUagd@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hailong.liu@oppo.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=mhocko@suse.com \
    --cc=urezki@gmail.com \
    --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.