On 01.11.2018 15:55, Michal Hocko wrote:
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.
But __GFP_NOWARN allocation (like in this case) should just fail silently
without warnings regardless of reason because caller can deal with that.
Without __GFP_NOWARN allocator should print standard warning.
Caller anyway must handle NULL\ENOMEM result - this error path
should be used for handling impossible sizes too.
Of course it could check size first, just as optimization.
