linux-kernel - RE: [PATCH] mm: remove all the slab allocators

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <eea7e17ab4264b7ca7ccea0ab725120f@AcuMS.aculab.com>
Date:   Sat, 1 Apr 2023 18:33:28 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Vlastimil Babka' <vbabka@...e.cz>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: RE: [PATCH] mm: remove all the slab allocators

From: Vlastimil Babka
> Sent: 32 March 2023 10:47
> 
> As the SLOB removal is on track and the SLAB removal is planned, I have
> realized - why should we stop there and not remove also SLUB? What's a
> slab allocator good for in 2023? The RAM sizes are getting larger and
> the modules cheaper [1]. The object constructor trick was perhaps
> interesting in 1994, but not with contemporary CPUs. So all the slab
> allocator does today is just adding an unnecessary layer of complexity
> over the page allocator.

Why stop there?
Remove kmalloc() completely.
With cheap memory isn't unreasonable to go back to compile-time
settable fixed size arrays for all items.
Should make 'use after free' much easier to track down.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)