From: Uladzislau Rezki <urezki@gmail.com>
To: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: "Uladzislau Rezki (Sony)" <urezki@gmail.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Michal Hocko <mhocko@kernel.org>, Baoquan He <bhe@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Alexander Potapenko <glider@google.com>
Subject: Re: [PATCH 5/8] mm/kasan, mm/vmalloc: Respect GFP flags in kasan_populate_vmalloc()
Date: Fri, 8 Aug 2025 12:18:29 +0200 [thread overview]
Message-ID: <aJXO9WwavhYFPykU@pc636> (raw)
In-Reply-To: <0d24f6b7-0e4c-4879-87f2-e31ad988baad@gmail.com>
On Thu, Aug 07, 2025 at 06:05:21PM +0200, Andrey Ryabinin wrote:
>
> On 8/7/25 9:58 AM, Uladzislau Rezki (Sony) wrote:
>
> > diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> > index d2c70cd2afb1..5edfc1f6b53e 100644
> > --- a/mm/kasan/shadow.c
> > +++ b/mm/kasan/shadow.c
> > @@ -335,13 +335,13 @@ static void ___free_pages_bulk(struct page **pages, int nr_pages)
> > }
> > }
> >
> > -static int ___alloc_pages_bulk(struct page **pages, int nr_pages)
> > +static int ___alloc_pages_bulk(struct page **pages, int nr_pages, gfp_t gfp_mask)
> > {
> > unsigned long nr_populated, nr_total = nr_pages;
> > struct page **page_array = pages;
> >
> > while (nr_pages) {
> > - nr_populated = alloc_pages_bulk(GFP_KERNEL, nr_pages, pages);
> > + nr_populated = alloc_pages_bulk(gfp_mask, nr_pages, pages);
> > if (!nr_populated) {
> > ___free_pages_bulk(page_array, nr_total - nr_pages);
> > return -ENOMEM;
> > @@ -353,25 +353,33 @@ static int ___alloc_pages_bulk(struct page **pages, int nr_pages)
> > return 0;
> > }
> >
> > -static int __kasan_populate_vmalloc(unsigned long start, unsigned long end)
> > +static int __kasan_populate_vmalloc(unsigned long start, unsigned long end, gfp_t gfp_mask)
> > {
> > unsigned long nr_pages, nr_total = PFN_UP(end - start);
> > + bool noblock = !gfpflags_allow_blocking(gfp_mask);
> > struct vmalloc_populate_data data;
> > + unsigned int flags;
> > int ret = 0;
>
> gfp_mask = (gfp_mask & GFP_RECLAIM_MASK);
>
>
> But it might be better to do this in alloc_vmap_area().
> In alloc_vmap_area() we have this:
>
> retry:
> if (IS_ERR_VALUE(addr)) {
> preload_this_cpu_lock(&free_vmap_area_lock, gfp_mask, node);
>
> which probably needs GFP_RECLAIM_MASK too.
>
Thank you for pointing to this. I will check it!
> >
> > - data.pages = (struct page **)__get_free_page(GFP_KERNEL | __GFP_ZERO);
> > + data.pages = (struct page **)__get_free_page(gfp_mask | __GFP_ZERO);
> > if (!data.pages)
> > return -ENOMEM;
> >
> > while (nr_total) {
> > nr_pages = min(nr_total, PAGE_SIZE / sizeof(data.pages[0]));
> > - ret = ___alloc_pages_bulk(data.pages, nr_pages);
> > + ret = ___alloc_pages_bulk(data.pages, nr_pages, gfp_mask);
> > if (ret)
> > break;
> >
> > data.start = start;
> > + if (noblock)
> > + flags = memalloc_noreclaim_save();
> > +
>
>
> This should be the same as in __vmalloc_area_node():
>
> if (noblock)
> flags = memalloc_noreclaim_save();
> else if ((gfp_mask & (__GFP_FS | __GFP_IO)) == __GFP_IO)
> flags = memalloc_nofs_save();
> else if ((gfp_mask & (__GFP_FS | __GFP_IO)) == 0)
> flags = memalloc_noio_save();
>
>
> It would be better to fix noio/nofs stuff first with separate patch, as it's
> bug and needs cc stable. And add support for noblock in follow up.
>
Right. KASAN was not fixed together with vmalloc. I will look into it.
> It might be a good idea to consolidate such logic in separate function,
> memalloc_save(gfp_mask)/memalloc_restore(gfp_mask, flags) ?
>
> > ret = apply_to_page_range(&init_mm, start, nr_pages * PAGE_SIZE,
> > kasan_populate_vmalloc_pte, &data);
> > + if (noblock)
> > + memalloc_noreclaim_restore(flags);
> > +
> > ___free_pages_bulk(data.pages, nr_pages);
> > if (ret)
>
Sounds good.
Thank you.
--
Uladzislau Rezki
next prev parent reply other threads:[~2025-08-08 10:18 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-07 7:58 [PATCH 0/8] __vmalloc() and no-block support Uladzislau Rezki (Sony)
2025-08-07 7:58 ` [PATCH 1/8] lib/test_vmalloc: add no_block_alloc_test case Uladzislau Rezki (Sony)
2025-08-07 7:58 ` [PATCH 2/8] lib/test_vmalloc: Remove xfail condition check Uladzislau Rezki (Sony)
2025-08-07 7:58 ` [PATCH 3/8] mm/vmalloc: Support non-blocking GFP flags in alloc_vmap_area() Uladzislau Rezki (Sony)
2025-08-07 11:20 ` Michal Hocko
2025-08-08 9:59 ` Uladzislau Rezki
2025-08-18 2:11 ` Baoquan He
2025-08-07 7:58 ` [PATCH 4/8] mm/vmalloc: Remove cond_resched() in vm_area_alloc_pages() Uladzislau Rezki (Sony)
2025-08-07 11:22 ` Michal Hocko
2025-08-08 10:08 ` Uladzislau Rezki
2025-08-18 2:14 ` Baoquan He
2025-08-07 7:58 ` [PATCH 5/8] mm/kasan, mm/vmalloc: Respect GFP flags in kasan_populate_vmalloc() Uladzislau Rezki (Sony)
2025-08-07 16:05 ` Andrey Ryabinin
2025-08-08 10:18 ` Uladzislau Rezki [this message]
2025-08-07 7:58 ` [PATCH 6/8] mm/vmalloc: Defer freeing partly initialized vm_struct Uladzislau Rezki (Sony)
2025-08-07 11:25 ` Michal Hocko
2025-08-08 10:37 ` Uladzislau Rezki
2025-08-18 4:21 ` Baoquan He
2025-08-18 13:02 ` Uladzislau Rezki
2025-08-19 8:56 ` Baoquan He
2025-08-19 9:20 ` Uladzislau Rezki
2025-08-07 7:58 ` [PATCH 7/8] mm/vmalloc: Support non-blocking GFP flags in __vmalloc_area_node() Uladzislau Rezki (Sony)
2025-08-07 11:54 ` Michal Hocko
2025-08-08 11:54 ` Uladzislau Rezki
2025-08-18 4:35 ` Baoquan He
2025-08-18 13:08 ` Uladzislau Rezki
2025-08-19 8:46 ` Baoquan He
2025-08-07 7:58 ` [PATCH 8/8] mm: Drop __GFP_DIRECT_RECLAIM flag if PF_MEMALLOC is set Uladzislau Rezki (Sony)
2025-08-07 11:58 ` Michal Hocko
2025-08-08 13:12 ` Uladzislau Rezki
2025-08-08 14:16 ` Michal Hocko
2025-08-08 16:56 ` Uladzislau Rezki
2025-08-07 11:01 ` [PATCH 0/8] __vmalloc() and no-block support Marco Elver
2025-08-08 8:48 ` Uladzislau Rezki
2025-08-23 9:35 ` Uladzislau Rezki
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=aJXO9WwavhYFPykU@pc636 \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=glider@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=ryabinin.a.a@gmail.com \
--cc=vbabka@suse.cz \
/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.