On Thu 01-11-18 13:48:17, Konstantin Khlebnikov wrote:
>
>
> On 01.11.2018 13:24, Michal Hocko wrote:
> > On Thu 01-11-18 13:09:16, Konstantin Khlebnikov wrote:
> > > Allocations over KMALLOC_MAX_SIZE could be served only by vmalloc.
> >
> > I would go on and say that allocations with sizes too large can actually
> > trigger a warning (once you have posted in the previous version outside
> > of the changelog area) because that might be interesting to people -
> > there are deployments to panic on warning and then a warning is much
> > more important.
>
> It seems that warning isn't completely valid.
>
>
> __alloc_pages_slowpath() handles this more gracefully:
>
> /*
> * In the slowpath, we sanity check order to avoid ever trying to
> * reclaim >= MAX_ORDER areas which will never succeed. Callers may
> * be using allocators in order of preference for an area that is
> * too large.
> */
> if (order >= MAX_ORDER) {
> WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
> return NULL;
> }
>
>
> Fast path is ready for order >= MAX_ORDER
>
>
> Problem is in node_reclaim() which is called earlier than __alloc_pages_slowpath()
> from surprising place - get_page_from_freelist()
>
>
> Probably node_reclaim() simply needs something like this:
>
> if (order >= MAX_ORDER)
> return NODE_RECLAIM_NOSCAN;
Maybe but the point is that triggering this warning is possible. Even if
the warning is bogus it doesn't really make much sense to even try
kmalloc if the size is not supported by the allocator.
--
Michal Hocko
SUSE Labs
