[PATCH v2 2/2] initmem: introduce CONFIG_INIT_ALL_HEAP
glider at google.com
Tue Apr 9 08:55:27 UTC 2019
On Mon, Apr 8, 2019 at 7:14 PM Kees Cook <keescook at chromium.org> wrote:
> On Mon, Apr 8, 2019 at 9:43 AM Laura Abbott <labbott at redhat.com> wrote:
> > I've looked at doing something similar in the past (failing to find
> > the thread this morning...) and while this will work, it has pretty
> > serious performance issues. It's not actually the poisoning which
> > is expensive but that turning on debugging removes the cpu slab
> > which has significant performance penalties.
> > I'd rather go back to the proposal of just poisoning the slab
> > at alloc/free without using SLAB_POISON.
> I still agree this would make the most sense. Fundamentally it's not a
> debugging feature.
Wasn't it you who suggested using SLAB_POISON in the first round of comments? :)
I actually have a working implementation that piggybacks on existing
__GFP_ZERO code to initialize page_alloc() and SLUB allocations:
I'd better cook a patch based on that.
There's also some overhead when allocations are initialized twice (in
page_alloc() and kmalloc()) or thrice (page_alloc(), kmalloc() and
We can introduce another GFP flag explicitly telling the allocator to
not initialize the memory chunk if we know it'll be initialized by a
higher level allocator
(something along the lines of
> Kees Cook
Google Germany GmbH
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
More information about the Linux-security-module-archive