From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751919AbcGNGwh (ORCPT <rfc822;w@1wt.eu>);
	Thu, 14 Jul 2016 02:52:37 -0400
Received: from LGEAMRELO12.lge.com ([156.147.23.52]:41434 "EHLO
	lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751241AbcGNGwa (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 14 Jul 2016 02:52:30 -0400
X-Original-SENDERIP: 156.147.1.121
X-Original-MAILFROM: iamjoonsoo.kim@lge.com
X-Original-SENDERIP: 10.177.222.138
X-Original-MAILFROM: iamjoonsoo.kim@lge.com
Date: Thu, 14 Jul 2016 15:56:21 +0900
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <adech.fo@gmail.com>, Christoph Lameter <cl@linux.com>,
        Dmitriy Vyukov <dvyukov@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Kostya Serebryany <kcc@google.com>,
        Andrey Ryabinin <aryabinin@virtuozzo.com>,
        Kuthonuzo Luruo <kuthonuzo.luruo@hpe.com>,
        kasan-dev <kasan-dev@googlegroups.com>,
        Linux Memory Management List <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6] mm, kasan: switch SLUB to stackdepot, enable memory
 quarantine for SLUB
Message-ID: <20160714065621.GC29676@js1304-P5Q-DELUXE>
References: <1467974210-117852-1-git-send-email-glider@google.com>
 <20160711060243.GA14107@js1304-P5Q-DELUXE>
 <CAG_fn=VM=nMFgKCGEHdD+A4TP9-8XoXKbXDyeXCc6ntkB16q0Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAG_fn=VM=nMFgKCGEHdD+A4TP9-8XoXKbXDyeXCc6ntkB16q0Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jul 12, 2016 at 03:02:19PM +0200, Alexander Potapenko wrote:
> >> +
> >>       /* Add alloc meta. */
> >>       cache->kasan_info.alloc_meta_offset = *size;
> >>       *size += sizeof(struct kasan_alloc_meta);
> >> @@ -392,17 +385,36 @@ void kasan_cache_create(struct kmem_cache *cache, size_t *size,
> >>           cache->object_size < sizeof(struct kasan_free_meta)) {
> >>               cache->kasan_info.free_meta_offset = *size;
> >>               *size += sizeof(struct kasan_free_meta);
> >> +     } else {
> >> +             cache->kasan_info.free_meta_offset = 0;
> >>       }
> >>       redzone_adjust = optimal_redzone(cache->object_size) -
> >>               (*size - cache->object_size);
> >> +
> >>       if (redzone_adjust > 0)
> >>               *size += redzone_adjust;
> >> -     *size = min(KMALLOC_MAX_CACHE_SIZE,
> >> +
> >> +#ifdef CONFIG_SLAB
> >> +     *size = min(KMALLOC_MAX_SIZE,
> >>                   max(*size,
> >>                       cache->object_size +
> >>                       optimal_redzone(cache->object_size)));
> >> -}
> >> +     /*
> >> +      * If the metadata doesn't fit, don't enable KASAN at all.
> >> +      */
> >> +     if (*size <= cache->kasan_info.alloc_meta_offset ||
> >> +                     *size <= cache->kasan_info.free_meta_offset) {
> >> +             *size = orig_size;
> >> +             return;
> >> +     }
> >> +#else
> >> +     *size = max(*size,
> >> +                     cache->object_size +
> >> +                     optimal_redzone(cache->object_size));
> >> +
> >>  #endif
> >
> > Hmm... could you explain why SLAB needs min(KMALLOC_MAX_SIZE, XX) but
> > not SLUB?
> 
> Because if the size is bigger than KMALLOC_MAX_SIZE then
> __kmem_cache_create() returns -E2BIG for SLAB. This happens right at
> startup in create_boot_cache().
> As far as I understand, SLUB doesn't have the upper limit (or is it
> that we just aren't hitting it?)

Perhaps, SLUB also has the upper limit although it wasn't triggered
easily since there is no such kmem_cache. Unlikely, SLAB has a such
sized kmem_cache in default (kmalloc-XXXXX). I haven't look at
calculate_order() in detail but it would give you some insight.

Thanks.