[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPrAcgM=-2dvHg5yvsqtT_YfjH-gThc+iGZGJpc8gpKbg-OdrA@mail.gmail.com>
Date: Tue, 23 Sep 2025 10:41:39 +0530
From: viswanath <viswanathiyyappan@...il.com>
To: Harry Yoo <harry.yoo@...cle.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 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
> 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?
> 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
Powered by blists - more mailing lists