Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp645141pxj; Thu, 13 May 2021 13:25:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyv0WJtps4kiVK+z5iFVFB/kkhH8wdnVrRzym3ddmO0NkkMzXxvkpJwexRFL7Xu9gttSHUa X-Received: by 2002:aa7:c691:: with SMTP id n17mr35487707edq.243.1620937544258; Thu, 13 May 2021 13:25:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620937544; cv=none; d=google.com; s=arc-20160816; b=vMo5XQK7pfrkMqIoEJlvOE9TJb9CGYxXpJUe6Vo7UUNhQ09yQk97Wyf1mrtj8rkDK6 sGANm/DRqY+Kye5IViFFSMpO2bHsBB8ZDN9DG9dtXYXyqC6MEds/kDHzRYm9IPaTOYvX NOVXH9+r0011mriWQuFr1xZ/lXAnc9OjVyaTqFck1F04CFCCc6iRCyrEkC9vItO7HV2t Nz+nw943XspM/1JeCANmJHr1v7mDA5Ts5fpcev6vo7gRqmxi5Kv5mTx1xO9ZRgHxRyIu zx33QbT+JXM/WF5Uz3NcMdUA2rrli1kFA5Cznpc3eIMQANx6vtVerL01wkAGmcT/nnZS Qx1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=6yM/wopgJf4+n6fWiQONoFUEzOPSr/VKODj2KnuocMc=; b=ci2bkXigvhCkZBjQOspVwfBgd3CzbexFNNWvs6sAimF3Vpt4ZWtZijd2F+cpP4PxVU DpItMFik0dHX6p2wHFmZqaHcQI6l9AhU6z3dVfM9M6YIjNr95U2MzN/vVNUv1Qff2XoF Ojvz8M9HugTV5YQU6ChEXVbUj1Ec3WEYW3MdtwtdGTydayzpELlx9mz5ttem1vuRQhsA huFIhn0EaLYD5t3TxNiWzdG0PrBKLlDO+phD92KB5brmbFlWXQ6ZM9n4aWlDUDlDLR4I oQwlGiW0MpzRTukpOvSgrpwT/Y3OTH9jYo1jZFV8wDbshLy0Y4pO28zufDk2sjAEpHcm o2QA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hA41ma5H; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rh9si4533255ejb.139.2021.05.13.13.25.19; Thu, 13 May 2021 13:25:44 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hA41ma5H; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233558AbhEMMjs (ORCPT + 99 others); Thu, 13 May 2021 08:39:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233028AbhEMMjm (ORCPT ); Thu, 13 May 2021 08:39:42 -0400 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8849BC061574 for ; Thu, 13 May 2021 05:38:29 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id 10so21751302pfl.1 for ; Thu, 13 May 2021 05:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6yM/wopgJf4+n6fWiQONoFUEzOPSr/VKODj2KnuocMc=; b=hA41ma5HOAxSYREyye75mEk/+G6y2z0v1vyBPxka2TGH2ITkZhkX/5aKDgYlsuLCFE ZtEL47wW4rIkbyqBl00kYxlVgXJwU909L6yB+bLuy05sZVnpTNoDyPjT+yi/3WxuW5LV ViQ+v8wZjHBkbOlIsUrrgcBlfub+8bOas1v4wKSX97cbLgieIifYul7q1VGZnLFENCVG Xgjaql5iN2IY8g1UtA3vLhVCNX+iNIgX+lJDII1YZvRYF/HiNtOgBxGbURBEWm1f4l5Z X1hT8ECKkmDZUZ9/24rNpIiXNimRCx9O+Fiog4/LGrhazeU0U3vwHq5lv4gurei7VGTM CUYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6yM/wopgJf4+n6fWiQONoFUEzOPSr/VKODj2KnuocMc=; b=jD33/XAkNPDhvloMrnRaZugr3wNmXZzNwiSEpx071LmU54vvvTMgrFPOm2CQELXiWI eyPhfn5fv6Kce/mSkCMRK0QeLUcdAe2jWDLJxtHoCDVjisnbyCSTacCX2mXQOeuc4wCe 7R48wPogO6FNIK63zFS1tkVFkDBWVTLS5TXwRo8ETSsAgujC44Hx+RM2S1E3+kuX+ojR TqQVGK8Azcf/W7nSliTa+XV4ovHmRdZbj9jyfD8bS9sfTzgPDducOuf+msFHzXwN9B1G 2BHIt/1umKUIQl+zZ1I8jy1Xpdh4ApdO5GR+AMZt70sF4DD86pBQf6ia+PSDQE7AWP1S BrwQ== X-Gm-Message-State: AOAM531LpCl2AypHfZcrWoUJc1/+bQNNQiiIE8S02gvL9LWpiVbqaBZh +7TZPWiWt5Mnv2ooL6OCc9c= X-Received: by 2002:a63:4a44:: with SMTP id j4mr40868160pgl.283.1620909509064; Thu, 13 May 2021 05:38:29 -0700 (PDT) Received: from hyeyoo ([121.135.181.35]) by smtp.gmail.com with ESMTPSA id t19sm2148448pgv.75.2021.05.13.05.38.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 May 2021 05:38:28 -0700 (PDT) Date: Thu, 13 May 2021 21:38:22 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Marco Elver Cc: Vlastimil Babka , Andrew Morton , Joonsoo Kim , David Rientjes , Pekka Enberg , Christoph Lameter , Linux Memory Management List , LKML Subject: Re: [PATCH v3] mm, slub: change run-time assertion in kmalloc_index() to compile-time Message-ID: <20210513123822.GA776220@hyeyoo> References: <20210511173448.GA54466@hyeyoo> <20210512195227.245000695c9014242e9a00e5@linux-foundation.org> <20210513031220.GA133011@hyeyoo> <20210512204024.401ff3de38649d7d0f5a45e8@linux-foundation.org> <20210513062809.GA319973@hyeyoo> <20210513120339.GA772931@hyeyoo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 13, 2021 at 02:29:13PM +0200, Marco Elver wrote: > On Thu, 13 May 2021 at 14:03, Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote: > > On Thu, May 13, 2021 at 12:31:38PM +0200, Marco Elver wrote: > [...] > > what about checking size it on top of kmalloc_index? because by definition of > > KMALLOC_SHIFT_HIGH, it's not always 25. it can be less than 25. for some > > situations. > > > > below is what I suggested beofre. for just reference: > > This doesn't solve the problem. We want the compiler to complain > whenever kmalloc_index() is used with non-constant in normal code. in the beginning, I thought kmalloc_index is called only from kmalloc. but if kmalloc_index is called from other place, I think it should correctly check its size. that's what kmalloc_index should do. or... should it be solved as another patch?