Re: [REPOST] [PATCH 2/2] mm: Fix potentially scheduling in GFP_ATOMIC allocations.

[David Rientjes <rientjes@google.com>]

On Thu, 3 Sep 2015, Tetsuo Handa wrote:

> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 5b5240b..7358225 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3046,15 +3046,8 @@ retry:
>  	}
>  
>  	/* Atomic allocations - we can't balance anything */
> -	if (!wait) {
> -		/*
> -		 * All existing users of the deprecated __GFP_NOFAIL are
> -		 * blockable, so warn of any new users that actually allow this
> -		 * type of allocation to fail.
> -		 */
> -		WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL);
> +	if (!wait)
>  		goto nopage;
> -	}
>  
>  	/* Avoid recursion of direct reclaim */
>  	if (current->flags & PF_MEMALLOC)
> @@ -3183,6 +3176,12 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
>  
>  	lockdep_trace_alloc(gfp_mask);
>  
> +	/*
> +	 * All existing users of the __GFP_NOFAIL have __GFP_WAIT.
> +	 * __GFP_NOFAIL allocations without __GFP_WAIT is unassured.
> +	 */
> +	WARN_ON_ONCE((gfp_mask & (__GFP_NOFAIL | __GFP_WAIT)) == __GFP_NOFAIL);
> +
>  	might_sleep_if(gfp_mask & __GFP_WAIT);
>  
>  	if (should_fail_alloc_page(gfp_mask, order))

This is correct, but since there are no GFP_ATOMIC | __GFP_NOFAIL callers 
in the tree, this would needlessly add the check to the fastpath and never 
trigger.  That's why it currently exists only in the slowpath.  It's more 
for documentation than actually triggering, although bug reports would 
always be welcome to report new callers.  Documentation can always be 
improved, however.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>