linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Vlastimil Babka <vbabka@suse.cz>,
	Andreas Dilger <adilger@dilger.ca>,
	John Hubbard <jhubbard@nvidia.com>,
	David Miller <davem@davemloft.net>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH] mm: convert three more cases to kvmalloc
Date: Fri, 30 Jun 2017 09:21:43 +0200	[thread overview]
Message-ID: <20170630072142.GA19931@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.LRH.2.02.1706292205110.21823@file01.intranet.prod.int.rdu2.redhat.com>

On Thu 29-06-17 22:13:26, Mikulas Patocka wrote:
> 
> 
> On Thu, 29 Jun 2017, Michal Hocko wrote:
[...]
> > > Index: linux-2.6/kernel/bpf/syscall.c
> > > ===================================================================
> > > --- linux-2.6.orig/kernel/bpf/syscall.c
> > > +++ linux-2.6/kernel/bpf/syscall.c
> > > @@ -58,16 +58,7 @@ void *bpf_map_area_alloc(size_t size)
> > >  	 * trigger under memory pressure as we really just want to
> > >  	 * fail instead.
> > >  	 */
> > > -	const gfp_t flags = __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO;
> > > -	void *area;
> > > -
> > > -	if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) {
> > > -		area = kmalloc(size, GFP_USER | flags);
> > > -		if (area != NULL)
> > > -			return area;
> > > -	}
> > > -
> > > -	return __vmalloc(size, GFP_KERNEL | flags, PAGE_KERNEL);
> > > +	return kvmalloc(size, GFP_USER | __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO);
> > 
> > kvzalloc without additional flags would be more appropriate.
> > __GFP_NORETRY is explicitly documented as non-supported
> 
> How is __GFP_NORETRY non-supported?

Because its semantic cannot be guaranteed throughout the alloaction
stack. vmalloc will ignore it e.g. for page table allocations.

> > and NOWARN wouldn't be applied everywhere in the vmalloc path.
> 
> __GFP_NORETRY and __GFP_NOWARN wouldn't be applied in the page-table 
> allocation and they would be applied in the page allocation - that seems 
> acceptable.

This is rather muddy semantic to me. Both page table and the page is an
order-0 allocation. Page table allocations are much less likely but I've
explicitly documented that explicit __GFP_NORETRY is unsupported. Slab
allocation is already __GFP_NORETRY (unless you specify
__GFP_RETRY_MAYFAIL in the current mmotm tree).
-- 
Michal Hocko
SUSE Labs

--
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>

      reply	other threads:[~2017-06-30  7:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-29  3:24 Mikulas Patocka
2017-06-29  7:10 ` Michal Hocko
2017-06-30  2:13   ` Mikulas Patocka
2017-06-30  7:21     ` Michal Hocko [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=20170630072142.GA19931@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=adilger@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpatocka@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --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