[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180323161512.GD5624@bombadil.infradead.org>
Date: Fri, 23 Mar 2018 09:15:12 -0700
From: Matthew Wilcox <willy@...radead.org>
To: Kirill Tkhai <ktkhai@...tuozzo.com>
Cc: linux-mm@...ck.org, Matthew Wilcox <mawilcox@...rosoft.com>,
linux-kernel@...r.kernel.org,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH 3/4] mm: Add free()
On Fri, Mar 23, 2018 at 08:14:21AM -0700, Matthew Wilcox wrote:
> > One more thing, there is
> > some kasan checks on the main way of kfree(), and there is no guarantee they
> > reflected in kmem_cache_free() identical.
>
> Which function are you talking about here?
>
> slub calls slab_free() for both kfree() and kmem_cache_free().
> slab calls __cache_free() for both kfree() and kmem_cache_free().
> Each of them do their kasan handling in the called function.
... except for where slub can free large objects without calling slab_free():
if (unlikely(!PageSlab(page))) {
BUG_ON(!PageCompound(page));
kfree_hook(object);
__free_pages(page, compound_order(page));
return;
}
slab_free(page->slab_cache, page, object, NULL, 1, _RET_IP_);
If you call kmalloc(16384, GFP_KERNEL), slub will hand back an order-2
page without setting PageSlab on it. So if that gets passed to free(),
it'll call __put_page() which calls free_compound_page() which calls
__free_pages_ok(). Looks like we want another compound_dtor to be sure
we call the kfree hook.
Powered by blists - more mailing lists