[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+CK2bCR0r61cnVxff6XSPoVN+ZxxS8rLHy0Mp6922xypCP8jA@mail.gmail.com>
Date: Thu, 23 Oct 2025 21:23:30 -0400
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Jason Miu <jasonmiu@...gle.com>, Alexander Graf <graf@...zon.com>,
Andrew Morton <akpm@...ux-foundation.org>, Baoquan He <bhe@...hat.com>,
Changyuan Lyu <changyuanl@...gle.com>, David Matlack <dmatlack@...gle.com>,
David Rientjes <rientjes@...gle.com>, Mike Rapoport <rppt@...nel.org>,
Pratyush Yadav <pratyush@...nel.org>, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v2 1/3] kho: Adopt KHO radix tree data structures
On Thu, Oct 23, 2025 at 7:45 PM Jason Gunthorpe <jgg@...dia.com> wrote:
>
> On Mon, Oct 20, 2025 at 03:03:04AM -0700, Jason Miu wrote:
>
> > +static struct kho_radix_tree *kho_alloc_radix_tree(void)
> > {
> > + return (struct kho_radix_tree *)get_zeroed_page(GFP_KERNEL);
> > +}
>
> I was reading the thread over here:
>
> https://lore.kernel.org/all/20151222210435.GB20997@ZenIV.linux.org.uk/
>
> And I guess this stuff should just use
> kzalloc(sizeof(struct kho_radix_tree), GFP_KERNEL);
kzalloc() uses slab, which in turn may use kfence objects, and kfence
can allocate memory from KHO scratch area, leading to memory
corruptions. Let's not use slab allocator for KHO preserved and
metadata memory, it is not a good choice.
Pasha
Powered by blists - more mailing lists