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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
