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
| ||
|
Message-ID: <895c88e8-b1f8-9ce3-8968-1c349c163b63@suse.cz> Date: Mon, 25 Oct 2021 10:19:04 +0200 From: Vlastimil Babka <vbabka@...e.cz> To: Hyeonggon Yoo <42.hyeyoo@...il.com> Cc: Rustam Kovhaev <rkovhaev@...il.com>, cl@...ux.com, penberg@...nel.org, rientjes@...gle.com, iamjoonsoo.kim@....com, akpm@...ux-foundation.org, djwong@...nel.org, david@...morbit.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org, gregkh@...uxfoundation.org, viro@...iv.linux.org.uk, dvyukov@...gle.com Subject: Re: [PATCH] slob: add size header to all allocations On 10/24/21 12:43, Hyeonggon Yoo wrote: >> >> >> >> The main reason for this change is to simplify SLOB a little bit, make >> >> it a bit easier to debug whenever something goes wrong. >> >> >> > >> > It seems acceptable But I wonder it is worth to increase memory usage >> > to allow freeing kmem_cache_alloc-ed objects by kfree()? >> >> Not for the reason above, but for providing a useful API guarantee >> regardless of selected slab allocator IMHO yes. >> > > Mm.. that means some callers free kmem_cache_alloc-ed object using > kfree, and SLAB/SLUB already support that, and SLOB doesn't. Exactly. Finding that out started this whole thread. > In what situations is freeing using kfree needed? > Wouldn't this make code confusing? XFS seems to have good reasons - at some common freeing place objects can appears from multiple caches, and it would be expensive to track their cache just to free them. See https://lore.kernel.org/all/20210930044202.GP2361455@dread.disaster.area/ IMHO it really makes sense to support this from API point of view. kmem_cache_alloc() is basically a more specific version of the generic kmalloc(). It makes sense if the generic kind of free, that is kfree() works on those objects too. >> > Thanks, >> > Hyeonggon >> > >> >> meminfo right after the system boot, without the patch: >> >> Slab: 35500 kB >> >> >> >> the same, with the patch: >> >> Slab: 36396 kB >> >> >> > >> >
Powered by blists - more mailing lists