From: Michal Hocko <mhocko@suse.com>
To: Barry Song <21cnbao@gmail.com>
Cc: vbabka@suse.cz, 42.hyeyoo@gmail.com, akpm@linux-foundation.org,
cl@linux.com, david@redhat.com, hailong.liu@oppo.com,
hch@infradead.org, iamjoonsoo.kim@lge.com, laoar.shao@gmail.com,
linux-hardening@vger.kernel.org, linux-mm@kvack.org,
penberg@kernel.org, rientjes@google.com,
roman.gushchin@linux.dev, torvalds@linux-foundation.org,
urezki@gmail.com, v-songbaohua@oppo.com,
virtualization@lists.linux.dev
Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation
Date: Fri, 30 Aug 2024 09:24:45 +0200 [thread overview]
Message-ID: <ZtFzvU1wiBSlhzzY@tiehlicka> (raw)
In-Reply-To: <20240829223114.1102-1-21cnbao@gmail.com>
On Fri 30-08-24 10:31:14, Barry Song wrote:
> > > > Patch 4/4: We will move the order > 1 check from the current fast path
> > > > to the slow path and extend
> > > > the check of gfp_direct_reclaim flag also in the slow path.
> > >
> > > OK, let's have that go in now as well.
>
> Hi Michal and Vlastimil,
> Could you please review the changes below before I send v4 for patch 4/4?
>
> 1. We should consolidate all warnings in one place. Currently, the order > 1 warning is
> in the hotpath, while others are in less likely scenarios. Moving all warnings to the
> slowpath will reduce the overhead for order > 1 and increase the visibility of other
> warnings.
>
> 2. We currently have two warnings for order: one for order > 1 in the hotpath and another
> for order > costly_order in the laziest path. I suggest standardizing on order > 1 since
> it’s been in use for a long time.
>
> 3.I don't think we need to check for __GFP_NOWARN in this case. __GFP_NOWARN is
> meant to suppress allocation failure reports, but here we're dealing with bug detection, not
> allocation failures.
> So I'd rather use WARN_ON_ONCE than WARN_ON_ONCE_GFP.
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c81ee5662cc7..0d3dd679d0ab 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3033,12 +3033,6 @@ struct page *rmqueue(struct zone *preferred_zone,
> {
> struct page *page;
>
> - /*
> - * We most definitely don't want callers attempting to
> - * allocate greater than order-1 page units with __GFP_NOFAIL.
> - */
> - WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1));
> -
> if (likely(pcp_allowed_order(order))) {
> page = rmqueue_pcplist(preferred_zone, zone, order,
> migratetype, alloc_flags);
> @@ -4174,6 +4168,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> struct alloc_context *ac)
> {
> bool can_direct_reclaim = gfp_mask & __GFP_DIRECT_RECLAIM;
> + bool nofail = gfp_mask & __GFP_DIRECT_RECLAIM;
> bool can_compact = gfp_compaction_allowed(gfp_mask);
> const bool costly_order = order > PAGE_ALLOC_COSTLY_ORDER;
> struct page *page = NULL;
> @@ -4187,6 +4182,25 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> unsigned int zonelist_iter_cookie;
> int reserve_flags;
>
> + if (nofail) {
> + /*
> + * We most definitely don't want callers attempting to
> + * allocate greater than order-1 page units with __GFP_NOFAIL.
> + */
> + WARN_ON_ONCE(order > 1);
> + /*
> + * Also we don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM,
> + * otherwise, we may result in lockup.
> + */
> + WARN_ON_ONCE(!can_direct_reclaim);
> + /*
> + * 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(current->flags & PF_MEMALLOC);
> + }
Yes, this makes sense. Any reason you have not put that int the nofail
branch below?
> +
> restart:
> compaction_retries = 0;
> no_progress_loops = 0;
> @@ -4404,29 +4418,15 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> * Make sure that __GFP_NOFAIL request doesn't leak out and make sure
> * we always retry
> */
> - if (gfp_mask & __GFP_NOFAIL) {
> + if (nofail) {
> /*
> - * All existing users of the __GFP_NOFAIL are blockable, so warn
> - * of any new users that actually require GFP_NOWAIT
> + * Lacking direct_reclaim we can't do anything to reclaim memory,
> + * we disregard these unreasonable nofail requests and still
> + * return NULL
> */
> - if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask))
> + if (!can_direct_reclaim)
> goto fail;
>
> - /*
> - * 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);
> -
> /*
> * Help non-failing allocations by giving some access to memory
> * reserves normally used for high priority non-blocking
>
> > >
> > > --
> > > Michal Hocko
> > > SUSE Labs
>
> Thanks
> Barry
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2024-08-30 7:24 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-17 6:24 [PATCH v3 0/4] mm: clarify nofail memory allocation Barry Song
2024-08-17 6:24 ` [PATCH v3 1/4] vduse: avoid using __GFP_NOFAIL Barry Song
2024-08-17 6:24 ` [PATCH v3 2/4] mm: document __GFP_NOFAIL must be blockable Barry Song
2024-08-17 6:24 ` [PATCH v3 3/4] mm: BUG_ON to avoid NULL deference while __GFP_NOFAIL fails Barry Song
2024-08-19 9:43 ` David Hildenbrand
2024-08-19 9:47 ` Barry Song
2024-08-19 9:55 ` David Hildenbrand
2024-08-19 10:02 ` Barry Song
2024-08-19 12:33 ` David Hildenbrand
2024-08-19 12:48 ` Barry Song
2024-08-19 12:49 ` David Hildenbrand
2024-08-19 17:12 ` Michal Hocko
2024-08-19 17:17 ` Linus Torvalds
2024-08-19 20:24 ` David Hildenbrand
2024-08-19 20:35 ` Linus Torvalds
2024-08-19 21:57 ` David Hildenbrand
2024-08-19 22:13 ` Linus Torvalds
2024-08-20 6:17 ` Michal Hocko
2024-08-19 12:49 ` Christoph Hellwig
2024-08-19 12:51 ` David Hildenbrand
2024-08-19 12:53 ` Christoph Hellwig
2024-08-19 13:14 ` David Hildenbrand
2024-08-19 13:05 ` Barry Song
2024-08-19 13:10 ` David Hildenbrand
2024-08-19 13:19 ` Barry Song
2024-08-19 13:22 ` David Hildenbrand
2024-08-17 6:24 ` [PATCH v3 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL Barry Song
2024-08-18 2:55 ` Yafang Shao
2024-08-18 3:48 ` Barry Song
2024-08-18 5:51 ` Yafang Shao
2024-08-18 6:27 ` Barry Song
2024-08-18 6:45 ` Barry Song
2024-08-18 7:07 ` Yafang Shao
2024-08-18 7:25 ` Barry Song
2024-08-19 7:51 ` Michal Hocko
2024-08-19 7:50 ` Michal Hocko
2024-08-19 9:25 ` Yafang Shao
2024-08-19 9:39 ` Barry Song
2024-08-19 9:45 ` Yafang Shao
2024-08-19 10:10 ` Barry Song
2024-08-19 11:56 ` Yafang Shao
2024-08-19 12:09 ` Michal Hocko
2024-08-19 12:17 ` Yafang Shao
2024-08-19 14:01 ` Michal Hocko
2024-08-19 10:17 ` Michal Hocko
2024-08-19 11:56 ` Yafang Shao
2024-08-19 12:04 ` Michal Hocko
2024-08-19 9:44 ` David Hildenbrand
2024-08-19 10:19 ` Michal Hocko
2024-08-19 12:48 ` David Hildenbrand
2024-08-19 13:02 ` [PATCH v3 0/4] mm: clarify nofail memory allocation David Hildenbrand
2024-08-19 16:05 ` Linus Torvalds
2024-08-19 19:23 ` Barry Song
2024-08-19 19:33 ` Linus Torvalds
2024-08-19 21:48 ` Barry Song
2024-08-20 6:24 ` Michal Hocko
2024-08-21 12:40 ` Yafang Shao
2024-08-21 22:59 ` Linus Torvalds
2024-08-22 6:21 ` Michal Hocko
2024-08-22 6:40 ` Linus Torvalds
2024-08-22 6:56 ` Linus Torvalds
2024-08-22 7:47 ` Michal Hocko
2024-08-22 7:57 ` Barry Song
2024-08-22 8:24 ` Michal Hocko
2024-08-22 8:39 ` David Hildenbrand
2024-08-22 9:08 ` Linus Torvalds
2024-08-22 9:16 ` Michal Hocko
2024-08-22 9:24 ` Linus Torvalds
2024-08-22 9:11 ` Michal Hocko
2024-08-22 9:18 ` Linus Torvalds
2024-08-22 9:33 ` Michal Hocko
2024-08-22 9:44 ` Linus Torvalds
2024-08-22 9:59 ` Michal Hocko
2024-08-22 10:30 ` Linus Torvalds
2024-08-22 10:46 ` Michal Hocko
2024-08-22 9:27 ` David Hildenbrand
2024-08-22 9:34 ` Linus Torvalds
2024-08-22 9:43 ` David Hildenbrand
2024-08-22 9:53 ` Linus Torvalds
2024-08-22 11:58 ` Johannes Weiner
2024-08-26 12:10 ` Vlastimil Babka
2024-08-27 6:57 ` Linus Torvalds
2024-08-27 7:15 ` Barry Song
2024-08-27 7:38 ` Vlastimil Babka
2024-08-27 7:50 ` Barry Song
2024-08-29 10:24 ` Vlastimil Babka
2024-08-29 11:53 ` Barry Song
2024-08-29 13:20 ` Michal Hocko
2024-08-29 21:27 ` Barry Song
2024-08-29 22:31 ` Barry Song
2024-08-30 7:24 ` Michal Hocko [this message]
2024-08-30 7:37 ` Vlastimil Babka
2024-08-22 9:41 ` Michal Hocko
2024-08-22 9:42 ` David Hildenbrand
2024-08-22 7:01 ` Gao Xiang
2024-08-22 7:54 ` Michal Hocko
2024-08-22 8:04 ` Gao Xiang
2024-08-22 14:35 ` Yafang Shao
2024-08-22 15:02 ` Gao Xiang
2024-08-22 6:37 ` Barry Song
2024-08-22 14:22 ` Yafang Shao
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=ZtFzvU1wiBSlhzzY@tiehlicka \
--to=mhocko@suse.com \
--cc=21cnbao@gmail.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=david@redhat.com \
--cc=hailong.liu@oppo.com \
--cc=hch@infradead.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=laoar.shao@gmail.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=torvalds@linux-foundation.org \
--cc=urezki@gmail.com \
--cc=v-songbaohua@oppo.com \
--cc=vbabka@suse.cz \
--cc=virtualization@lists.linux.dev \
/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.