On Thu, 25 Sep 2014, Dmitry Vyukov wrote:
> > + depends on SLUB_DEBUG
>
>
> What does SLUB_DEBUG do? I think that generally we don't want any
> other *heavy* debug checks to be required for kasan.
SLUB_DEBUG includes the capabilties for debugging. It does not switch
debug on by default. SLUB_DEBUG_ON will results in a kernel that boots
with active debugging. Without SLUB_DEBUG_ON a kernel parameter activates
debugging.
> > +{
> > + unsigned long size = cache->size;
> > + unsigned long rounded_up_size = round_up(size, KASAN_SHADOW_SCALE_SIZE);
> > +
>
> Add a comment saying that SLAB_DESTROY_BY_RCU objects can be "legally"
> used after free.
Add "within the rcu period"
> > static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
> > @@ -1416,8 +1426,10 @@ static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
> > setup_object(s, page, p);
> > if (likely(idx < page->objects))
> > set_freepointer(s, p, p + s->size);
>
> Sorry, I don't fully follow this code, so I will just ask some questions.
> Can we have some slab padding after last object in this case as well?
This is the free case. If poisoing is enabled then the object will be
overwritten on free. Padding is used depending on the need to align the
object and is optional. Redzoning will occur if requested. Are you asking
for redzoning?
> kasan_mark_slab_padding poisons only up to end of the page. Can there
> be multiple pages that we need to poison?
If there is a higher order page then only the end portion needs to be
poisoned. Objects may straddle order 0 boundaries then.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>