[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <56DD96F4.1060805@suse.cz>
Date: Mon, 7 Mar 2016 15:57:56 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Michal Hocko <mhocko@...nel.org>, Nikolay Borisov <kernel@...p.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: remove __GFP_NOFAIL is deprecated comment
On 02/25/2016 02:48 PM, Michal Hocko wrote:
> On Thu 25-02-16 13:36:11, Nikolay Borisov wrote:
> - if (unlikely(gfp_flags & __GFP_NOFAIL)) {
> - /*
> - * __GFP_NOFAIL is not to be used in new code.
> - *
> - * All __GFP_NOFAIL callers should be fixed so that they
> - * properly detect and handle allocation failures.
> - *
> - * We most definitely don't want callers attempting to
> - * allocate greater than order-1 page units with
> - * __GFP_NOFAIL.
> - */
> - WARN_ON_ONCE(order > 1);
> - }
> + /*
> + * 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));
> spin_lock_irqsave(&zone->lock, flags);
>
> page = NULL;
>
Hmm, even the reduced text (and the WARN_ON in the first place) sounds
IMHO discouraging enough to make people think that opencoding a loop
around such allocations is a good workaround. Yeah, we have a
better/more thorough explanation around the __GFP_NOFAIL definition, but
the WARN_ON will point people here.
Powered by blists - more mailing lists