From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C168C4682 for ; Mon, 26 Sep 2022 18:24:39 +0000 (UTC) Received: by mail-pf1-f179.google.com with SMTP id 9so7492188pfz.12 for ; Mon, 26 Sep 2022 11:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=4OBTQRXHJygCpY/2rBSvNKQlNNozBBa3mtJlOeJ/EyY=; b=cSzvTXKu85TucB7q+g9CQdjC/FdnYJW7ESEBDVMDQZhpqkoHzMT6tB5vmqaaVmtq+c HBo/BI5kdAn7jf+xxq5MiOLWI7cJumnHX29hS+SWLXo9wgZxYqgGZ4IjXwCG6/+UPFiS mSjP6/8kEubWj+KXOsoeUGGJwGHBMRMvzL4Ek= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=4OBTQRXHJygCpY/2rBSvNKQlNNozBBa3mtJlOeJ/EyY=; b=L8S5EcGqsb5sJFX+NYDt+1bA/mHyX3ON2HirfbH4htgw30rwRVd2WEnpAL9wCTqIfe y2tbmOzEqvZL+zp11GWxLTNeKwtnRIjMKyQY1jIBwU3ZHc8U6BOBP7T8FtN4HwasIxtn PIurYe+mY97prF9ae+w4X1wErsuEliZQaGRQgX++qeoRyv2F0hzoRSxFNVt5RHUQfuHD WBs/M6U1r6gS4ZO2CCQckHjGzF8ZM2U1y+Jjmz+7PXd8EDRGliW/6xHbFeJAGM5IMLZs hUITl4W6swWa8BllIH2cdQ4VynC0gKFFwoepsRT8h0pvxmfrGVL7/IiNwDXFKb1n7bjg NZQg== X-Gm-Message-State: ACrzQf1SDjzzTLbVlfOdEtONkoB/aiJkEEd5voi1xjceIJSAVZgkTREQ Npp2qW/FjRay2BMxqFGuW3x8Uw== X-Google-Smtp-Source: AMsMyM6gzz3RlLPDBF6eEAacYBSNNxOrYYdXLeQNzcYYWROPiLY1NScn4aUnW3BZuZbnjPt9v5tgLQ== X-Received: by 2002:a63:4750:0:b0:43c:dac:9e4b with SMTP id w16-20020a634750000000b0043c0dac9e4bmr21137736pgk.300.1664216679159; Mon, 26 Sep 2022 11:24:39 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id p2-20020a170902c70200b0016f85feae65sm11305644plp.87.2022.09.26.11.24.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Sep 2022 11:24:38 -0700 (PDT) Date: Mon, 26 Sep 2022 11:24:37 -0700 From: Kees Cook To: Vlastimil Babka Cc: Andrew Morton , linux-mm@kvack.org, "Ruhl, Michael J" , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Greg Kroah-Hartman , Nick Desaulniers , Alex Elder , Josef Bacik , David Sterba , Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , Jesse Brandeburg , Daniel Micay , Yonghong Song , Marco Elver , Miguel Ojeda , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-fsdevel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, dev@openvswitch.org, x86@kernel.org, llvm@lists.linux.dev, linux-hardening@vger.kernel.org Subject: Re: [PATCH v2 13/16] mempool: Use kmalloc_size_roundup() to match ksize() usage Message-ID: <202209261123.B2CBAE87E0@keescook> References: <20220923202822.2667581-1-keescook@chromium.org> <20220923202822.2667581-14-keescook@chromium.org> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Sep 26, 2022 at 03:50:43PM +0200, Vlastimil Babka wrote: > On 9/23/22 22:28, Kees Cook wrote: > > Round up allocations with kmalloc_size_roundup() so that mempool's use > > of ksize() is always accurate and no special handling of the memory is > > needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE. > > > > Cc: Andrew Morton > > Cc: linux-mm@kvack.org > > Signed-off-by: Kees Cook > > --- > > mm/mempool.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/mempool.c b/mm/mempool.c > > index 96488b13a1ef..0f3107b28e6b 100644 > > --- a/mm/mempool.c > > +++ b/mm/mempool.c > > @@ -526,7 +526,7 @@ EXPORT_SYMBOL(mempool_free_slab); > > */ > > void *mempool_kmalloc(gfp_t gfp_mask, void *pool_data) > > { > > - size_t size = (size_t)pool_data; > > + size_t size = kmalloc_size_roundup((size_t)pool_data); > > Hm it is kinda wasteful to call into kmalloc_size_roundup for every > allocation that has the same input. We could do it just once in > mempool_init_node() for adjusting pool->pool_data ? > > But looking more closely, I wonder why poison_element() and > kasan_unpoison_element() in mm/mempool.c even have to use ksize()/__ksize() > and not just operate on the requested size (again, pool->pool_data). If no > kmalloc mempool's users use ksize() to write beyond requested size, then we > don't have to unpoison/poison that area either? Yeah, I think that's a fair point. I will adjust this. -- Kees Cook From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E9A95C07E9D for ; Mon, 26 Sep 2022 18:24:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0177510E754; Mon, 26 Sep 2022 18:24:42 +0000 (UTC) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by gabe.freedesktop.org (Postfix) with ESMTPS id A13C210E754 for ; Mon, 26 Sep 2022 18:24:39 +0000 (UTC) Received: by mail-pg1-x532.google.com with SMTP id 129so5872829pgc.5 for ; Mon, 26 Sep 2022 11:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=4OBTQRXHJygCpY/2rBSvNKQlNNozBBa3mtJlOeJ/EyY=; b=cSzvTXKu85TucB7q+g9CQdjC/FdnYJW7ESEBDVMDQZhpqkoHzMT6tB5vmqaaVmtq+c HBo/BI5kdAn7jf+xxq5MiOLWI7cJumnHX29hS+SWLXo9wgZxYqgGZ4IjXwCG6/+UPFiS mSjP6/8kEubWj+KXOsoeUGGJwGHBMRMvzL4Ek= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=4OBTQRXHJygCpY/2rBSvNKQlNNozBBa3mtJlOeJ/EyY=; b=Svj9uSiiEAGkGP/FR09Y5mhiZPR/4hanxOIxOAbAUhC4EEWPiPxI5CvMDlf8bkGyd+ IOi2mbm1jZPAzc1nFBnfBfEI/NGl1W67HM+Ag0MQhemdtwaAbkqgCNTwGg72Nw6qKj3G uST1cD7tAkX4mj+42Lyj5FmFUmfe2OsenAf37zoxb45nZmiVZZ5JSIDQAnm+fafPhqKA e3uoJFRbptXrevOF+KiCUv3d14qvjwsnVRrQtLtaeenmI2Fwws4vE/+X0orKvK5bIVLz U7eGqdueBNvLuHOeL+xBYqhhCZMM7A1OeLupKEQoJwalT0EbMJCaqLPciraQVX1/Krig 61OQ== X-Gm-Message-State: ACrzQf0Ds0WDqdwVHqirdaL6lVsXFDCl5P9UynUZa9Bfg43mXbT4FWxq ZjZ/Fky4rEkbAh47SR0eC43tfg== X-Google-Smtp-Source: AMsMyM6gzz3RlLPDBF6eEAacYBSNNxOrYYdXLeQNzcYYWROPiLY1NScn4aUnW3BZuZbnjPt9v5tgLQ== X-Received: by 2002:a63:4750:0:b0:43c:dac:9e4b with SMTP id w16-20020a634750000000b0043c0dac9e4bmr21137736pgk.300.1664216679159; Mon, 26 Sep 2022 11:24:39 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id p2-20020a170902c70200b0016f85feae65sm11305644plp.87.2022.09.26.11.24.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Sep 2022 11:24:38 -0700 (PDT) Date: Mon, 26 Sep 2022 11:24:37 -0700 From: Kees Cook To: Vlastimil Babka Subject: Re: [PATCH v2 13/16] mempool: Use kmalloc_size_roundup() to match ksize() usage Message-ID: <202209261123.B2CBAE87E0@keescook> References: <20220923202822.2667581-1-keescook@chromium.org> <20220923202822.2667581-14-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: llvm@lists.linux.dev, dri-devel@lists.freedesktop.org, "Ruhl, Michael J" , Eric Dumazet , linux-hardening@vger.kernel.org, Hyeonggon Yoo <42.hyeyoo@gmail.com>, Christoph Lameter , Sumit Semwal , dev@openvswitch.org, x86@kernel.org, Jesse Brandeburg , intel-wired-lan@lists.osuosl.org, David Rientjes , Miguel Ojeda , Yonghong Song , Paolo Abeni , linux-media@vger.kernel.org, Marco Elver , Josef Bacik , linaro-mm-sig@lists.linaro.org, Jakub Kicinski , David Sterba , Andrew Morton , Alex Elder , linux-mm@kvack.org, Greg Kroah-Hartman , Nick Desaulniers , linux-kernel@vger.kernel.org, Christian =?iso-8859-1?Q?K=F6nig?= , Pekka Enberg , Daniel Micay , netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, Joonsoo Kim , "David S. Miller" , linux-btrfs@vger.kernel.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Sep 26, 2022 at 03:50:43PM +0200, Vlastimil Babka wrote: > On 9/23/22 22:28, Kees Cook wrote: > > Round up allocations with kmalloc_size_roundup() so that mempool's use > > of ksize() is always accurate and no special handling of the memory is > > needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE. > > > > Cc: Andrew Morton > > Cc: linux-mm@kvack.org > > Signed-off-by: Kees Cook > > --- > > mm/mempool.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/mempool.c b/mm/mempool.c > > index 96488b13a1ef..0f3107b28e6b 100644 > > --- a/mm/mempool.c > > +++ b/mm/mempool.c > > @@ -526,7 +526,7 @@ EXPORT_SYMBOL(mempool_free_slab); > > */ > > void *mempool_kmalloc(gfp_t gfp_mask, void *pool_data) > > { > > - size_t size = (size_t)pool_data; > > + size_t size = kmalloc_size_roundup((size_t)pool_data); > > Hm it is kinda wasteful to call into kmalloc_size_roundup for every > allocation that has the same input. We could do it just once in > mempool_init_node() for adjusting pool->pool_data ? > > But looking more closely, I wonder why poison_element() and > kasan_unpoison_element() in mm/mempool.c even have to use ksize()/__ksize() > and not just operate on the requested size (again, pool->pool_data). If no > kmalloc mempool's users use ksize() to write beyond requested size, then we > don't have to unpoison/poison that area either? Yeah, I think that's a fair point. I will adjust this. -- Kees Cook From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3ED06C6FA82 for ; Mon, 26 Sep 2022 18:24:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id D9D958151E; Mon, 26 Sep 2022 18:24:43 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D9D958151E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1664216683; bh=Af7k041I3JcI+kGy2AgcJN171vvxAGd+Is/7KswbjLU=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=yoP25lhgZSgEm4XX8szBBFnMKsHHQOKI72MUUiAlN7mmHwBjIX73kC0+kw0NyMAye Fai/0JmLpnlu2Tg/JhR0JS9vBz7keGBefjAcso1AOpkKc6JMzBVEp06b6707eQfvZV +4VP3Y+dSD93Nv/d4mvml/rEVd3gPfPBUBXn4ERB/XCTCZFTD+fjuYCnDEuD95Y0C2 HRsi5Nj5Yd8GYVPWietu+UVvmpoxyfionKZjwsE3E5zWmQcK5cC5eLcto3jgRyDyMF ZZ3BX9YdEqki6KCqCfYNOBWWk4i7tgub/ZOW1eOrH5u0XsHvwyzUzXQeNAxq4z5r74 w5VfO+ixMz3nw== X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiW5t34WpQLh; Mon, 26 Sep 2022 18:24:43 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp1.osuosl.org (Postfix) with ESMTP id D3E5C81756; Mon, 26 Sep 2022 18:24:42 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D3E5C81756 Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by ash.osuosl.org (Postfix) with ESMTP id 4F60B1BF2F5 for ; Mon, 26 Sep 2022 18:24:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 32CF741878 for ; Mon, 26 Sep 2022 18:24:41 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 32CF741878 X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRIvCrsrizHl for ; Mon, 26 Sep 2022 18:24:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org BFE5C41827 Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by smtp4.osuosl.org (Postfix) with ESMTPS id BFE5C41827 for ; Mon, 26 Sep 2022 18:24:39 +0000 (UTC) Received: by mail-pf1-x434.google.com with SMTP id e68so7550528pfe.1 for ; Mon, 26 Sep 2022 11:24:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=4OBTQRXHJygCpY/2rBSvNKQlNNozBBa3mtJlOeJ/EyY=; b=quBEDySDtANxEAYaI1a4uOQFrUr6I3BIHkzP/8F+DhoQ1eFeV++D94M+AZnVBLsqKz s98Zz0N1+Ami6JoA+ENCjbKmw3lyBxS3FRALIRdfHWY8SSDsuTNdKHAHAPfwNrf20pjs bwywqDcjPhlelqFIXH0pJ492Phffq1ta2LvTC9f+D/6+fWNjHLmvDbf8kxraMMBJRs8t r6TIeHTFNdiWYEnwaVt7Qot9PjV2y5frZFEN5SC4O5zKlhPeSVAwVNSB6iD3Pmg2K2qb YXk1IYrN5Ryj/IA+BrQHqlJV/Hyv5lFx/vCLAcXzsxxQWA63Zto+SpNdQrOb1M1fACgd QoOQ== X-Gm-Message-State: ACrzQf1yWYQe/RiN421B8TELOEtKMN4Dfl64FlL+gG/ox7jnGcg3fM7V jdlULTm+feDkeKudI3P4Mv9AUw== X-Google-Smtp-Source: AMsMyM6gzz3RlLPDBF6eEAacYBSNNxOrYYdXLeQNzcYYWROPiLY1NScn4aUnW3BZuZbnjPt9v5tgLQ== X-Received: by 2002:a63:4750:0:b0:43c:dac:9e4b with SMTP id w16-20020a634750000000b0043c0dac9e4bmr21137736pgk.300.1664216679159; Mon, 26 Sep 2022 11:24:39 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id p2-20020a170902c70200b0016f85feae65sm11305644plp.87.2022.09.26.11.24.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Sep 2022 11:24:38 -0700 (PDT) Date: Mon, 26 Sep 2022 11:24:37 -0700 From: Kees Cook To: Vlastimil Babka Message-ID: <202209261123.B2CBAE87E0@keescook> References: <20220923202822.2667581-1-keescook@chromium.org> <20220923202822.2667581-14-keescook@chromium.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=4OBTQRXHJygCpY/2rBSvNKQlNNozBBa3mtJlOeJ/EyY=; b=cSzvTXKu85TucB7q+g9CQdjC/FdnYJW7ESEBDVMDQZhpqkoHzMT6tB5vmqaaVmtq+c HBo/BI5kdAn7jf+xxq5MiOLWI7cJumnHX29hS+SWLXo9wgZxYqgGZ4IjXwCG6/+UPFiS mSjP6/8kEubWj+KXOsoeUGGJwGHBMRMvzL4Ek= X-Mailman-Original-Authentication-Results: smtp4.osuosl.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256 header.s=google header.b=cSzvTXKu Subject: Re: [Intel-wired-lan] [PATCH v2 13/16] mempool: Use kmalloc_size_roundup() to match ksize() usage X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: llvm@lists.linux.dev, dri-devel@lists.freedesktop.org, "Ruhl, Michael J" , Eric Dumazet , linux-hardening@vger.kernel.org, Hyeonggon Yoo <42.hyeyoo@gmail.com>, Christoph Lameter , Sumit Semwal , dev@openvswitch.org, x86@kernel.org, intel-wired-lan@lists.osuosl.org, David Rientjes , Miguel Ojeda , Yonghong Song , Paolo Abeni , linux-media@vger.kernel.org, Marco Elver , Josef Bacik , linaro-mm-sig@lists.linaro.org, Jakub Kicinski , David Sterba , Andrew Morton , Alex Elder , linux-mm@kvack.org, Greg Kroah-Hartman , Nick Desaulniers , linux-kernel@vger.kernel.org, Christian =?iso-8859-1?Q?K=F6nig?= , Pekka Enberg , Daniel Micay , netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, Joonsoo Kim , "David S. Miller" , linux-btrfs@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On Mon, Sep 26, 2022 at 03:50:43PM +0200, Vlastimil Babka wrote: > On 9/23/22 22:28, Kees Cook wrote: > > Round up allocations with kmalloc_size_roundup() so that mempool's use > > of ksize() is always accurate and no special handling of the memory is > > needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE. > > > > Cc: Andrew Morton > > Cc: linux-mm@kvack.org > > Signed-off-by: Kees Cook > > --- > > mm/mempool.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/mempool.c b/mm/mempool.c > > index 96488b13a1ef..0f3107b28e6b 100644 > > --- a/mm/mempool.c > > +++ b/mm/mempool.c > > @@ -526,7 +526,7 @@ EXPORT_SYMBOL(mempool_free_slab); > > */ > > void *mempool_kmalloc(gfp_t gfp_mask, void *pool_data) > > { > > - size_t size = (size_t)pool_data; > > + size_t size = kmalloc_size_roundup((size_t)pool_data); > > Hm it is kinda wasteful to call into kmalloc_size_roundup for every > allocation that has the same input. We could do it just once in > mempool_init_node() for adjusting pool->pool_data ? > > But looking more closely, I wonder why poison_element() and > kasan_unpoison_element() in mm/mempool.c even have to use ksize()/__ksize() > and not just operate on the requested size (again, pool->pool_data). If no > kmalloc mempool's users use ksize() to write beyond requested size, then we > don't have to unpoison/poison that area either? Yeah, I think that's a fair point. I will adjust this. -- Kees Cook _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan