[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aNI6t5hqY6hSx_8Z@hyeyoo>
Date: Tue, 23 Sep 2025 15:14:35 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: viswanath <viswanathiyyappan@...il.com>
Cc: vbabka@...e.cz, akpm@...ux-foundation.org, cl@...two.org,
rientjes@...gle.com, roman.gushchin@...ux.dev, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, skhan@...uxfoundation.org,
david.hunter.linux@...il.com, linux-kernel-mentees@...ts.linux.dev,
syzbot+94d20db923b9f51be0df@...kaller.appspotmail.com
Subject: Re: [RFC PATCH] mm/slab: Add size validation in kmalloc_array_*
functions
On Tue, Sep 23, 2025 at 10:41:39AM +0530, viswanath wrote:
> On Mon, 22 Sept 2025 at 23:30, Harry Yoo <harry.yoo@...cle.com> wrote:
>
> > When bytes > KKMALLOC_MAX_SIZE (8K on my system), kmalloc redirects allocation
> > to the buddy allocator, which can allocate up to (PAGE_SIZE << MAX_PAGE_ORDER)
> > bytes (4M on my system).
>
> In include/linux/slab.h,
> KMALLOC_MAX_SIZE is ultimately defined as PAGE_SIZE << MAX_PAGE_ORDER and
> KMALLOC_MAX_CACHE_SIZE as PAGE_SIZE << 1
>
> I was using those definitions
Err, you're right :) you mentioned KMALLOC_MAX_SIZE, not
KMALLOC_MAX_CACHE_SIZE. Apologies for the confusion.
> > Because allocating a page with order > MAX_PAGE_ORDER page is never
> > supposed to succeed, the caller of kmalloc should be fixed rather than
> > kmalloc itself.
>
> So, Is it almost never a good idea to add new validation in the allocator code?
Yes, because such allocations will always fail and that's never a good
thing.
> > I think the right fix should be to return -EINVAL in max_vclocks_store()
> > if max * sizeof(int) exceeds PAGE_SIZE << MAX_PAGE_ORDER?
>
> Thanks, I will go ahead with this approach
>
> Thanks,
> Viswanath
--
Cheers,
Harry / Hyeonggon
Powered by blists - more mailing lists