Received: by 2002:a05:6520:4211:b029:f4:110d:56bc with SMTP id o17csp3132972lkv; Mon, 10 May 2021 08:23:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwbX2gUNULWKc+eiKfL4w3o6/nkGPLVBFrllUYmFYvJmYrsKrceUT062oY0bigfjon5FSO X-Received: by 2002:a05:6602:2d8f:: with SMTP id k15mr18174990iow.114.1620660188231; Mon, 10 May 2021 08:23:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620660188; cv=none; d=google.com; s=arc-20160816; b=dgcLJ2XkBpBd8OYUbLiOmRAZvVxW3+om+Jp+DWIruJM4tnOfbdkt4JSDtGZLmcsi0R FccsYJVZj6MQcQ4QoV2slyDP8b/SARHWdnGeSH0Jf8L5hy5vMqssJC41UnegJ05Cpvws YI6pGScUbJZIWd7ovSxVKGgw+CSvnBMl9f8YI/o5ghzHrN0YxGbI5JKRKkrNWgV6eshf xnQOU6ILNHEwOM9uo8kdtOOOqYac1/reek42qAva9NZ71ROEMf0SA+FPr37u9+/I0IMX QSgc7frVHcCFiU5QjKb4FLzsdeihG9ZTS9Aj/P2vs+fmV0NZV4cvf9bX8ODwNEClhkjF 6Ceg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=MaMCFRqhCkB44fKhxvDZs1Uajc2EtlGwPhHDC6BL8WE=; b=Ourn61wL9xOCYpvtlsA5MrdJAgQO86/SO1XbOo8AV014yd9E7VTvN7UZtOL7joxK44 UstFYmqLi/lxwIRmR/8cVDrBoS5gElhmyQzehmUDvjLNDY2fIV+QSJo1mnaZ8ROU+Gi1 sle5COnSPPj6K2QzvbuDSBYsYufWsxXzRSfAxoG99RjifnZo6vnlY2hGw3109PY9fQRi DjEEDkMVv4rQpSMh4UpdtRO0W3ld8LeHrRTma5BlTMrZO0FQLXlMLtOOldETzyDOssg/ YS48/G1DLvSZ8eSC+CvVp8kXRVhxXRcyyjojhC/J3EYEx5UiYHjqnlsCqjc6wv/+x1q2 2COA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z10si16097427ilp.153.2021.05.10.08.22.56; Mon, 10 May 2021 08:23:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234809AbhEJPXW (ORCPT + 99 others); Mon, 10 May 2021 11:23:22 -0400 Received: from mx2.suse.de ([195.135.220.15]:58618 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237620AbhEJPXB (ORCPT ); Mon, 10 May 2021 11:23:01 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 5292AAD5C; Mon, 10 May 2021 15:21:54 +0000 (UTC) Subject: Re: [PATCH v2] mm: kmalloc_index: make compiler break when size is not supported To: Christoph Lameter , Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Matthew Wilcox , penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20210508221328.7338-1-42.hyeyoo@gmail.com> <20210510135857.GA3594@hyeyoo> <9d0ffe49-a2e2-6c81-377b-4c8d2147dff8@suse.cz> <20210510150230.GA74915@hyeyoo> From: Vlastimil Babka Message-ID: <409cdbf2-7574-b7ed-b456-b8388b53ef10@suse.cz> Date: Mon, 10 May 2021 17:21:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/10/21 5:15 PM, Christoph Lameter wrote: > I guess this needs to be reviewed and tested by the users of architectures > that can use large MAXORDER pages such as powerpc and Itanium. AFAICS large MAX_ORDER should matter as KMALLOC_SHIFT_HIGH will be always capped to 25. But sure, let the bots complain if something is wrong. I'm more interested if we shake out some compiler that can't do the compile-time evaluation properly and we didn't know until now. > On Tue, 11 May 2021, Hyeonggon Yoo wrote: > >> updated patch. let me know if something is wrong! >> > > > 0001-mm-kmalloc_index-make-compiler-break-when-size-is-no.patch > >>From 8fe7ecdfb0f5bd5b08771512303d72f1c6447362 Mon Sep 17 00:00:00 2001 > From: Hyeonggon Yoo <42.hyeyoo@gmail.com> > Date: Mon, 10 May 2021 23:57:34 +0900 > Subject: [PATCH] mm: kmalloc_index: make compiler break when size is not > supported > > currently when size is not supported by kmalloc_index, compiler will not > break. so changed BUG to BUILD_BUG_ON_MSG to make compiler break if size is > wrong. this is done in compile time. > > also removed code that allocates more than 32MB because current > implementation supports only up to 32MB. > > Signed-off-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > --- > include/linux/slab.h | 7 +++++-- > mm/slab_common.c | 7 +++---- > 2 files changed, 8 insertions(+), 6 deletions(-) > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index 0c97d788762c..fd0c7229d105 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -346,6 +346,9 @@ static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags) > * 1 = 65 .. 96 bytes > * 2 = 129 .. 192 bytes > * n = 2^(n-1)+1 .. 2^n > + * > + * Note: you don't need to optimize kmalloc_index because it's evaluated > + * in compile-time. > */ > static __always_inline unsigned int kmalloc_index(size_t size) > { > @@ -382,8 +385,8 @@ static __always_inline unsigned int kmalloc_index(size_t size) > if (size <= 8 * 1024 * 1024) return 23; > if (size <= 16 * 1024 * 1024) return 24; > if (size <= 32 * 1024 * 1024) return 25; > - if (size <= 64 * 1024 * 1024) return 26; > - BUG(); > + > + BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()"); > > /* Will never be reached. Needed because the compiler may complain */ > return -1; > diff --git a/mm/slab_common.c b/mm/slab_common.c > index f8833d3e5d47..39d4eca8cf9b 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -745,8 +745,8 @@ struct kmem_cache *kmalloc_slab(size_t size, gfp_t flags) > > /* > * kmalloc_info[] is to make slub_debug=,kmalloc-xx option work at boot time. > - * kmalloc_index() supports up to 2^26=64MB, so the final entry of the table is > - * kmalloc-67108864. > + * kmalloc_index() supports up to 2^25=32MB, so the final entry of the table is > + * kmalloc-33554432. > */ > const struct kmalloc_info_struct kmalloc_info[] __initconst = { > INIT_KMALLOC_INFO(0, 0), > @@ -774,8 +774,7 @@ const struct kmalloc_info_struct kmalloc_info[] __initconst = { > INIT_KMALLOC_INFO(4194304, 4M), > INIT_KMALLOC_INFO(8388608, 8M), > INIT_KMALLOC_INFO(16777216, 16M), > - INIT_KMALLOC_INFO(33554432, 32M), > - INIT_KMALLOC_INFO(67108864, 64M) > + INIT_KMALLOC_INFO(33554432, 32M) > }; > > /* >