On 7/16/23 13:28, Matthew Wilcox wrote: > On Sun, Jul 16, 2023 at 06:10:44PM +0700, Bagas Sanjaya wrote: >> Hi, >> >> I notice a regression report on Bugzilla [1]. Quoting from it: > > Maybe you could try doing some work on this bug before just spamming > people with it? > > if (WARN_ON_ONCE_GFP(order > MAX_ORDER, gfp)) > return NULL; > > This is the page allocator telling the caller that they've asked for an > unreasonably large allocation. > > Now, this bug is actually interesting to the MM because the caller > called kmalloc() with a ridiculous size. Arguable kmalloc should > protect callers from themselves (alloc_pages() is more low level > and can presume its users know what they're doing). > > Vlastimil, what do you think? Something like ... Hmm should be more robust to check size > KMALLOC_MAX_SIZE before even doing get_order(size). Ultimately it checks the same limit. But I'm unsure about just returning NULL. I think warn_on_once might be useful even there - in case a bug is introduced/exposed, even a inexperienced user will be easily able to report sufficient information wich a WARN and its stacktrace, even if the callsite's alloc check doesn't provide it in an obvious way? > +++ b/mm/slab_common.c > @@ -1119,6 +1119,8 @@ static void *__kmalloc_large_node(size_t size, gfp_t flags, int node) > void *ptr = NULL; > unsigned int order = get_order(size); > > + if (order > MAX_ORDER) > + return NULL; > if (unlikely(flags & GFP_SLAB_BUG_MASK)) > flags = kmalloc_fix_flags(flags); > > >
