Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp191146ybz; Tue, 21 Apr 2020 07:17:19 -0700 (PDT) X-Google-Smtp-Source: APiQypJzm08AJCRYGTecPluWR5rKomT9X8Yho4YbLyNR4Nh5AXc9AZcZT/leduwTFvsZEXTkKopu X-Received: by 2002:a05:6402:95e:: with SMTP id h30mr14223886edz.117.1587478639130; Tue, 21 Apr 2020 07:17:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587478639; cv=none; d=google.com; s=arc-20160816; b=sGa/MurY9ZytULde8lZ1A/NUwx5ZXXTeUl7V2BQFJ4hJX0KisSx7p+AEkZU/coxLHQ CXihPucMIZrLHScb8HgSAY1zQpUMj+jx3xu55Ou9vlNo3tT35nJpYk25TyMW6kj8qdO5 pSYC9JWCvF+iw8KOA2WaHIXTJP7I4gjWxh7W1jaqxbCEPSUBBoUC7vUz4Teta8O9CFXj JsvLzaAcCUWnXC1llt4+VNxVU6vGXcSCJG8m0Qb/qWJ9+MDpKmZn7KFn2/CJKM0fke+S I7I0cm5Lm090eSQO4PHyYqFqKeCwBgkfNjYZKbJ9TZMp07nWD9E4p/a7GrIdEwXw5Av8 VfXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=oa6hkSxC0ZVbrStuNGnVGl7ziCniGNedf2/U4LUuXUU=; b=a24jCX2A7o1Zn/jUFC9JicZrgqb2O2X6gSCCCqrwQxCLohs8qlvJhgGUTIY2YND6C9 oUJ77SHjHaIN0YRT1FrE65JLn9Kjfjwb/Rbbmo33Yxo1j9dhDhzAgehDflN78IeMFjrP pjVbX4+Gtkp5C7qCPj+NWPjcARmPCFNCpR8TY0PUBGJjDJuiauxVRtbAJitZYd6XEQ8g bwe8G7+X95L4/qlxZm+g7T0bjP8qj3VpzdRF/autg+1hNZnoZuN6X+qs0uo6nHS+uvxo Mq9BTJ8s9SHzGXTmCXJcFBNBnRYzv08Fwk/T8yd4/e5+OyL0OT8UOpezEyenQFg1mzZN HMhA== 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 c8si1718812ejr.252.2020.04.21.07.16.55; Tue, 21 Apr 2020 07:17:19 -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 S1728803AbgDUOPh (ORCPT + 99 others); Tue, 21 Apr 2020 10:15:37 -0400 Received: from mx2.suse.de ([195.135.220.15]:52196 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726018AbgDUOPh (ORCPT ); Tue, 21 Apr 2020 10:15:37 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A1E0AAEF7; Tue, 21 Apr 2020 14:15:35 +0000 (UTC) Subject: Re: [PATCH] kmalloc_index optimization(add kmalloc max size check) To: Bernard Zhao , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: kernel@vivo.com References: <1587107376-111722-1-git-send-email-bernard@vivo.com> From: Vlastimil Babka Message-ID: <05bedc84-3672-975c-87ee-f094ca766ee8@suse.cz> Date: Tue, 21 Apr 2020 16:15:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <1587107376-111722-1-git-send-email-bernard@vivo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/17/20 9:09 AM, Bernard Zhao wrote: > kmalloc size should never exceed KMALLOC_MAX_SIZE. > kmalloc_index realise if size is exceed KMALLOC_MAX_SIZE, e.g 64M, > kmalloc_index just return index 26, but never check with OS`s max > kmalloc config KMALLOC_MAX_SIZE. This index`s kmalloc caches maybe > not create in function create_kmalloc_caches. > We can throw an warninginfo in kmalloc at the beginning, instead of > being guaranteed by the buddy alloc behind. > > Signed-off-by: Bernard Zhao kmalloc_index() is only called from kmalloc() and kmalloc_node() for compile-time constant sizes up to KMALLOC_MAX_CACHE_SIZE, which is smaller (SLUB, SLOB) or equal (SLAB) than KMALLOC_MAX_SIZE. So your patch is effectively a no-op and we better shouldn't tease the compiler too much, so that kmalloc_index() stays fully compile-time evaluated. > --- > include/linux/slab.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index 6d45488..59b60d2 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -351,6 +351,10 @@ static __always_inline unsigned int kmalloc_index(size_t size) > if (!size) > return 0; > > + /* size should never exceed KMALLOC_MAX_SIZE. */ > + if (size > KMALLOC_MAX_SIZE) > + WARN(1, "size exceed max kmalloc size!\n"); > + > if (size <= KMALLOC_MIN_SIZE) > return KMALLOC_SHIFT_LOW; > >