From: Barry Song <21cnbao@gmail.com>
To: Hailong Liu <hailong.liu@oppo.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
Barry Song <v-songbaohua@oppo.com>,
Michal Hocko <mhocko@suse.com>,
Uladzislau Rezki <urezki@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Lorenzo Stoakes <lstoakes@gmail.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>
Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL
Date: Thu, 18 Jul 2024 20:33:39 +1200 [thread overview]
Message-ID: <CAGsJ_4xAdBct_ggFHCMFsAK83Gdh_8T0w6aDtzEOaPGOc1d3KA@mail.gmail.com> (raw)
In-Reply-To: <20240718074816.w7drfptbunkvpukd@oppo.com>
On Thu, Jul 18, 2024 at 7:48 PM Hailong Liu <hailong.liu@oppo.com> wrote:
>
> On Thu, 18. Jul 11:00, Barry Song wrote:
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > Overflow in this context is highly unlikely. However, allocations using
> > GFP_NOFAIL are guaranteed to succeed, so checking the return value is
> > unnecessary. One option to fix this is allowing memory allocation with
> > an overflowed size, but it seems pointless. Let's at least issue a
> > warning. Likely BUG_ON() seems better as anyway we can't fix it?
> >
> > Cc: Michal Hocko <mhocko@suse.com>
> > Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
> > Cc: Christoph Hellwig <hch@infradead.org>
> > Cc: Lorenzo Stoakes <lstoakes@gmail.com>
> > Cc: Christoph Lameter <cl@linux.com>
> > Cc: Pekka Enberg <penberg@kernel.org>
> > Cc: David Rientjes <rientjes@google.com>
> > Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> > Cc: Vlastimil Babka <vbabka@suse.cz>
> > Cc: Roman Gushchin <roman.gushchin@linux.dev>
> > Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> > ---
> > include/linux/slab.h | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/slab.h b/include/linux/slab.h
> > index a332dd2fa6cd..c6aec311864f 100644
> > --- a/include/linux/slab.h
> > +++ b/include/linux/slab.h
> > @@ -692,8 +692,10 @@ static inline __alloc_size(1, 2) void *kmalloc_array_noprof(size_t n, size_t siz
> > {
> > size_t bytes;
> >
> > - if (unlikely(check_mul_overflow(n, size, &bytes)))
> > + if (unlikely(check_mul_overflow(n, size, &bytes))) {
> > + WARN_ON(flags & __GFP_NOFAIL);
> Hi Barry:
>
> IMO, using __GFP_NOFAIL guarantees success if and only if the parameters are *correct*.
> Maybe we can add here to help callers to find the reason as in mm/page_alloc.c
no, this doesn't make any sense:
* %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
* cannot handle allocation failures. The allocation could block
* indefinitely but will never return with failure. Testing for
* failure is pointless.
I believe these are two separate things at different layers.
>
> ```
> if (gfp_mask & __GFP_NOFAIL) {
> /*
> * All existing users of the __GFP_NOFAIL are blockable, so warn
> * of any new users that actually require GFP_NOWAIT
> */
> if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask))
> goto fail;
If the code calling this function doesn't have a retry mechanism, it is
a BUG that needs to be fixed. even though the above code might return
NULL, its wrapper will still retry, for example:
while (nr_allocated < nr_pages) {
if (!nofail && fatal_signal_pending(current))
break;
if (nid == NUMA_NO_NODE)
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;
}
/*
* Higher order allocations must be able to be treated as
* indepdenent small pages by callers (as they can with
* small-page vmallocs). Some drivers do their own refcounting
* on vmalloc_to_page() pages, some use page->mapping,
* page->lru, etc.
*/
if (order)
split_page(page, order);
/*
* Careful, we allocate and map page-order pages, but
* tracking is done per PAGE_SIZE page so as to keep the
* vm_struct APIs independent of the physical/mapped size.
*/
for (i = 0; i < (1U << order); i++)
pages[nr_allocated + i] = page + i;
cond_resched();
nr_allocated += 1U << order;
}
>
> /*
> * PF_MEMALLOC request from this context is rather bizarre
> * because we cannot reclaim anything and only can loop waiting
> * for somebody to do a work for us
> */
> WARN_ON_ONCE_GFP(current->flags & PF_MEMALLOC, gfp_mask);
>
> /*
> * non failing costly orders are a hard requirement which we
> * are not prepared for much so let's warn about these users
> * so that we can identify them and convert them to something
> * else.
> */
> WARN_ON_ONCE_GFP(costly_order, gfp_mask);
> ```
>
> > return NULL;
> > + }
> > if (__builtin_constant_p(n) && __builtin_constant_p(size))
> > return kmalloc_noprof(bytes, flags);
> > return kmalloc_noprof(bytes, flags);
> > @@ -794,8 +796,10 @@ kvmalloc_array_node_noprof(size_t n, size_t size, gfp_t flags, int node)
> > {
> > size_t bytes;
> >
> > - if (unlikely(check_mul_overflow(n, size, &bytes)))
> > + if (unlikely(check_mul_overflow(n, size, &bytes))) {
> > + WARN_ON(flags & __GFP_NOFAIL);
> > return NULL;
> > + }
> >
> > return kvmalloc_node_noprof(bytes, flags, node);
> > }
> > --
> > 2.34.1
> >
> >
>
> --
> help you, help me,
> Hailong.
Thanks
Barry
prev parent reply other threads:[~2024-07-18 8:33 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-17 23:00 Barry Song
2024-07-18 6:58 ` Michal Hocko
2024-07-18 7:04 ` Christoph Hellwig
2024-07-18 7:12 ` Michal Hocko
2024-07-18 8:16 ` Vlastimil Babka
2024-07-18 7:22 ` Barry Song
2024-07-18 7:27 ` Michal Hocko
2024-07-18 7:41 ` Barry Song
2024-07-18 7:53 ` Michal Hocko
2024-07-18 8:18 ` Barry Song
2024-07-18 8:32 ` Michal Hocko
2024-07-18 8:43 ` Barry Song
2024-07-18 8:50 ` Michal Hocko
2024-07-19 0:35 ` Barry Song
2024-07-19 7:02 ` Michal Hocko
2024-07-19 7:07 ` Barry Song
2024-07-19 7:42 ` Michal Hocko
2024-07-19 7:51 ` Barry Song
2024-07-19 8:01 ` Michal Hocko
2024-07-19 8:28 ` Barry Song
2024-07-19 8:40 ` Michal Hocko
2024-07-19 9:36 ` Barry Song
2024-07-19 9:45 ` Michal Hocko
2024-07-19 9:58 ` Barry Song
2024-07-19 10:57 ` Michal Hocko
2024-07-19 11:05 ` Barry Song
2024-07-19 11:19 ` Michal Hocko
2024-07-19 8:50 ` Vlastimil Babka
2024-07-19 9:33 ` Michal Hocko
2024-07-19 10:10 ` Vlastimil Babka
2024-07-19 10:52 ` Michal Hocko
2024-07-19 11:13 ` Vlastimil Babka
2024-07-19 11:26 ` Michal Hocko
2024-07-19 13:02 ` Barry Song
2024-07-19 13:30 ` Michal Hocko
2024-07-20 0:36 ` Barry Song
2024-07-22 7:23 ` Michal Hocko
2024-07-22 7:34 ` Vlastimil Babka
2024-07-19 7:37 ` Christoph Hellwig
2024-07-19 7:43 ` Barry Song
2024-07-19 7:53 ` Christoph Hellwig
2024-07-20 22:14 ` Barry Song
2024-07-22 7:26 ` Michal Hocko
2024-07-22 8:09 ` Barry Song
2024-07-22 9:01 ` Michal Hocko
2024-07-22 23:18 ` Christoph Hellwig
2024-07-22 23:22 ` Barry Song
2024-07-19 8:35 ` Vlastimil Babka
2024-07-18 7:48 ` Hailong Liu
2024-07-18 8:33 ` Barry Song [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=CAGsJ_4xAdBct_ggFHCMFsAK83Gdh_8T0w6aDtzEOaPGOc1d3KA@mail.gmail.com \
--to=21cnbao@gmail.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=hailong.liu@oppo.com \
--cc=hch@infradead.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=mhocko@suse.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=urezki@gmail.com \
--cc=v-songbaohua@oppo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox