lkml.org 
[lkml]   [2022]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2 13/16] mempool: Use kmalloc_size_roundup() to match ksize() usage
From
On 9/23/22 22:28, Kees Cook wrote:
> Round up allocations with kmalloc_size_roundup() so that mempool's use
> of ksize() is always accurate and no special handling of the memory is
> needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: linux-mm@kvack.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> mm/mempool.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/mempool.c b/mm/mempool.c
> index 96488b13a1ef..0f3107b28e6b 100644
> --- a/mm/mempool.c
> +++ b/mm/mempool.c
> @@ -526,7 +526,7 @@ EXPORT_SYMBOL(mempool_free_slab);
> */
> void *mempool_kmalloc(gfp_t gfp_mask, void *pool_data)
> {
> - size_t size = (size_t)pool_data;
> + size_t size = kmalloc_size_roundup((size_t)pool_data);

Hm it is kinda wasteful to call into kmalloc_size_roundup for every
allocation that has the same input. We could do it just once in
mempool_init_node() for adjusting pool->pool_data ?

But looking more closely, I wonder why poison_element() and
kasan_unpoison_element() in mm/mempool.c even have to use
ksize()/__ksize() and not just operate on the requested size (again,
pool->pool_data). If no kmalloc mempool's users use ksize() to write
beyond requested size, then we don't have to unpoison/poison that area
either?

> return kmalloc(size, gfp_mask);
> }
> EXPORT_SYMBOL(mempool_kmalloc);

\
 
 \ /
  Last update: 2022-09-26 17:13    [W:0.123 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site