All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: Barry Song <21cnbao@gmail.com>,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	42.hyeyoo@gmail.com, cl@linux.com, hch@infradead.org,
	iamjoonsoo.kim@lge.com, lstoakes@gmail.com, penberg@kernel.org,
	rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com,
	v-songbaohua@oppo.com, vbabka@suse.cz,
	virtualization@lists.linux.dev, hailong.liu@oppo.com,
	torvalds@linux-foundation.org
Subject: Re: [PATCH RFC 5/5] non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL
Date: Mon, 5 Aug 2024 09:49:06 +0200	[thread overview]
Message-ID: <ZrCD8kRTLD67MrRw@tiehlicka> (raw)
In-Reply-To: <3mevqjzu2emxd2f3zkrurnzcal67k4lpkcdqzfs75qhp4uflbn@skz6q5odetdr>

On Sat 03-08-24 15:15:56, Davidlohr Bueso wrote:
> On Mon, 29 Jul 2024, Michal Hocko wrote:
> > Because it is really hard to figure out what it is supposed to mean.
> > If the caller uses __GFP_NOFAIL then it is (should be) impossible and if
> > NOFAIL is not used then why does it need to check for
> > 	(gfp & ~__GFP_NOFAIL) != GFP_KERNEL?
> 
> Agreed, this is pointless - and cannot recall why it was justified to have
> in the first place.
> 
> But I think we should revert back to the original check then, which is there
> to distinguish failure cases between normal (GFP_KERNEL) and nested (GFP_ATOMIC)
> contexts. Removing the check altogether would change the fallback for regular
> allocations.
> 
> So this would be:
> 
> -       if (tbl == NULL && (gfp & ~__GFP_NOFAIL) != GFP_KERNEL) {
> +       if (tbl == NULL && gfp != GFP_KERNEL) {

If you want to tell between sleeping and atomic allocations then already
mentioned gfpflags_allow_blocking would be more readable IMHO but the
above is much better already.
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2024-08-05  7:49 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-24  8:55 [PATCH 0/5] mm: clarify nofail memory allocation Barry Song
2024-07-24  8:55 ` [PATCH RFC 1/5] vpda: try to fix the potential crash due to misusing __GFP_NOFAIL Barry Song
2024-07-24 12:26   ` Michal Hocko
2024-07-24 22:50     ` Barry Song
2024-07-25  6:08       ` Michal Hocko
2024-07-25  7:00         ` Barry Song
2024-07-29  3:42           ` Jason Wang
2024-07-29  6:05             ` Barry Song
2024-07-30  2:48               ` Jason Wang
2024-07-30  3:08                 ` Barry Song
2024-07-30  3:13                   ` Jason Wang
2024-07-24  8:55 ` [PATCH 2/5] mm: Document __GFP_NOFAIL must be blockable Barry Song
2024-07-24 11:58   ` Michal Hocko
2024-08-03 23:09   ` Davidlohr Bueso
2024-07-24  8:55 ` [PATCH 3/5] mm: BUG_ON to avoid NULL deference while __GFP_NOFAIL fails Barry Song
2024-07-24 10:03   ` Vlastimil Babka
2024-07-24 10:11     ` Barry Song
2024-07-24 12:10   ` Michal Hocko
2024-07-24  8:55 ` [PATCH 4/5] mm: Introduce GFP_NOFAIL with the inclusion of __GFP_RECLAIM Barry Song
2024-07-24 12:12   ` Michal Hocko
2024-07-24  8:55 ` [PATCH RFC 5/5] non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL Barry Song
2024-07-24  9:53   ` Vlastimil Babka
2024-07-24  9:58     ` Barry Song
2024-07-24 13:14       ` Christoph Hellwig
2024-07-24 12:25     ` Michal Hocko
2024-07-24 13:13     ` Christoph Hellwig
2024-07-24 13:21       ` Michal Hocko
2024-07-24 13:23         ` Christoph Hellwig
2024-07-24 13:31           ` Michal Hocko
2024-07-24 13:33             ` Vlastimil Babka
2024-07-24 13:38               ` Christoph Hellwig
2024-07-24 13:47                 ` Michal Hocko
2024-07-24 13:55                   ` Christoph Hellwig
2024-07-24 14:39                     ` Vlastimil Babka
2024-07-24 14:41                       ` Christoph Hellwig
2024-07-25  1:47                         ` Barry Song
2024-07-29  9:56                           ` Barry Song
2024-07-29 10:03                             ` Vlastimil Babka
2024-07-29 10:16                               ` Barry Song
2024-07-24 12:17   ` Michal Hocko
2024-07-25  1:38     ` Barry Song
2024-07-25  6:16       ` Michal Hocko
2024-07-26 21:08         ` Davidlohr Bueso
2024-07-29 11:50           ` Michal Hocko
2024-08-03 22:15             ` Davidlohr Bueso
2024-08-05  7:49               ` Michal Hocko [this message]
2024-07-25  1:17   ` kernel test robot
2024-07-25 14:20   ` Dan Carpenter
  -- strict thread matches above, loose matches on Subject: below --
2024-07-25  6:38 kernel test robot

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=ZrCD8kRTLD67MrRw@tiehlicka \
    --to=mhocko@suse.com \
    --cc=21cnbao@gmail.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=dave@stgolabs.net \
    --cc=hailong.liu@oppo.com \
    --cc=hch@infradead.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --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.