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 C5C04C32771 for ; Mon, 26 Sep 2022 13:50:49 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 885BA10E6B7; Mon, 26 Sep 2022 13:50:48 +0000 (UTC) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3678610E6B7 for ; Mon, 26 Sep 2022 13:50:46 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id BD2191F381; Mon, 26 Sep 2022 13:50:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1664200244; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4+nnignD8u93QTMbO+4vxufOtmSDjzXgxDuRW+9Vc+Y=; b=wXNPeKYY807oTGOEqp5VUsWItY4N/bf2FG0PYuKf/76ya/XWXoSBlutnZ1v4V7ZTVE24Jq kcDNiVz+QDDTZinU63vcP0aQKnt9DxgJ/Il0N5ifhw8+wIaLXqfcS4eEjoUOz7O6KuQRXh 6XNfMe0qLNWn1mp8715x1o53Ql+qjsY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1664200244; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4+nnignD8u93QTMbO+4vxufOtmSDjzXgxDuRW+9Vc+Y=; b=HGu2wC9OaQUC3t9QLyIF5OanWAJ3MVeu2wqtrCmlnZR0Vt3rj6ay/cPA71LiUBug2kTQ26 BQkvYbGQFVWjp7Dw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 275AE139BD; Mon, 26 Sep 2022 13:50:44 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id cuKbCDSuMWOIeAAAMHmgww (envelope-from ); Mon, 26 Sep 2022 13:50:44 +0000 Message-ID: Date: Mon, 26 Sep 2022 15:50:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH v2 13/16] mempool: Use kmalloc_size_roundup() to match ksize() usage Content-Language: en-US To: Kees Cook References: <20220923202822.2667581-1-keescook@chromium.org> <20220923202822.2667581-14-keescook@chromium.org> From: Vlastimil Babka In-Reply-To: <20220923202822.2667581-14-keescook@chromium.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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, =?UTF-8?Q?Christian_K=c3=b6nig?= , 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 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? > return kmalloc(size, gfp_mask); > } > EXPORT_SYMBOL(mempool_kmalloc);