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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6810FC2D0CD for ; Thu, 15 May 2025 16:01:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA4F96B00A6; Thu, 15 May 2025 12:01:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D52B56B00A7; Thu, 15 May 2025 12:01:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF4356B00A8; Thu, 15 May 2025 12:01:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A229D6B00A6 for ; Thu, 15 May 2025 12:01:16 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 64E05BFAF9 for ; Thu, 15 May 2025 16:01:17 +0000 (UTC) X-FDA: 83445606594.16.584DD5B Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf23.hostedemail.com (Postfix) with ESMTP id 6C2E6140027 for ; Thu, 15 May 2025 16:01:15 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MDi+M5+I; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of kees@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=kees@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747324875; h=from:from:sender:reply-to:subject:subject: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:dkim-signature; bh=7/mg0RJpxFicrlOCvMJmYCqpa93OiqhoDazhFYD+Ias=; b=CxQtIznKULCUtcLKqck38JW9RGb4EyJAXH2zduYnQEP4HgwbmutAhAkdfxKOis7eST05tY 9YTQorB5b3Z0kpAIaDA+ht6H9q1hTFvFd9oaASkqgHCRthY0Up2G00m6rtozI3h3N6d1SD LmYC2UQv4B6IkrJWK4MUh4xYwRwNCek= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747324875; a=rsa-sha256; cv=none; b=0B2sx/HVOdBzEefJKZMuGsE42rBqubvM9depSYN009Fpr1vrOkT8o/w0CC47gybcl6yMvO HtoFBiq9vqp1bwyPyOXEurr5kFf2SsC8CPTMhZEohsNW4dJFvpL5rdIifZ+o9dCYgntWyP +K/XPfLTIyrzdin10NvWsWBBhK40J7o= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MDi+M5+I; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of kees@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=kees@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 338DB49B3A; Thu, 15 May 2025 16:01:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C1DBC4CEE7; Thu, 15 May 2025 16:01:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747324874; bh=mO2vcNgJs8+C51CBW2wKe8JPfH5wo/ZFqAzhliVrj1c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MDi+M5+IEOa8F8YxVPfRIoBbxDt0YTFoGBaBOVS70e9hMJCQ0t6D0ndEzpewYJOT4 0NMokKbLnbBVGZ2NjAk56NaIzsHOCrGH9g3Dkm9lLgOZkl+oidWYj+Bufki1PKuU6V BZ1dWVFI2HgsVyeafoVJ7v3fDpSQrkqVE4KJ/1MJsDPZ3Q7gBM/S7Yn71c4payYMNU GdjEP1gNRNWE64PoCaWfmml/BtK+kvZUUIR/syw5QDzWCElTgaq2dQVDXbWbu8vWA7 7+uGQV7mEUQwa4at9/shgXnShD5NLTQyz+MDO//3OCdjla0ypcgAnbgrHduR2zDMLx JX0B2yekJMZdw== Date: Thu, 15 May 2025 09:01:11 -0700 From: Kees Cook To: Andrii Nakryiko Cc: Shung-Hsi Yu , bpf@vger.kernel.org, linux-mm@kvack.org, Andrii Nakryiko , Ihor Solodrai , Andrew Morton , Michal Hocko , Vlastimil Babka , Uladzislau Rezki , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, regressions@lists.linux.dev, Greg Kroah-Hartman , Alexei Starovoitov , Daniel Borkmann , Pawan Gupta , Eduard Zingerman Subject: Re: [REGRESSION] bpf verifier slowdown due to vrealloc() change since 6.15-rc6 Message-ID: <202505150900.13CFA05B7@keescook> References: <20250515-bpf-verifier-slowdown-vwo2meju4cgp2su5ckj@6gi6ssxbnfqg> <202505150845.0F9E154@keescook> <202505150850.6F3E261D67@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: ys36uqcyzb81xmjdrgmjebf76fcreokk X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6C2E6140027 X-HE-Tag: 1747324875-707565 X-HE-Meta: U2FsdGVkX19t1Wi3CPgZsJa+Au/vSsz4KukoQyeRhrDF3ZFwAYJ1mutc9FjmMgychcgjszFlMuVuuMghTpHkHr5sR+tjEMkNIzOr4bvdoWTG4NmmeuNa1RvlOI2zWwVqcRnIyiUbmGurQe7BM0ziTJ3ghRe3Gnfka1sCvWP22u0mi4Uj31GD5clioMEHJwpD8vEEr0/kLAvShqOO6hjb8MT0f1pfIjuy7HJ/O+kYgBlsKDTYdUIIuOIBJepk+/80B39texY9xzFlN9e208gnzoZRe5LId1rl5/xxczDVcdBOoAnXnGohe6dxk4QhKiAI5kWqWT05Hopgl7oDKl0rU4x1PdRUwDpZNyAZcYPb9HdcvjiMMngBKE0QALQxWfWx0NYt+M7c3a1maxwysSidoSnIg4LaBTSmaZcwFutB2dH4Ph6A21gcYqeE5BJaHnNLJpHNsOgAgplrMcThMPHvv13E4+KLuLihxYbxtYERaMOJoZFQG7hnra60JvwXQq7rBmQAwJ5gWZ3NyDNE6z6S4M66281z3BxIumpkANhBKsZu/jJ5S0JsypNmOyjnly/ETOhDEzE6WAgzCheckwBwecZxkXmiLU5SiDenorMSsnBLS9Td3qIhANLzj0ZH+yr0VqETV5PRATreDmWqnShvQbhLePLS9DXGylXfvU+TpJa359e/nbJcrtIRGGmiMlujQWwZwKkt3iDIVXwpFZREJ6RqF9sBDAEZ0ADGQ8NPfMR1ZdgBgJUImGxX5F0pe8j7BKWIYWbtTw9NDLEVU7NTi1JInaGr7jkomg2v+KtSKd2KOJyHCnWh6QcO6ZqyuDlRKF3JdIdqoFMVJ6VGiYBgFVa5wwFocCsATXJjBtqECFtYM0/8DCOzcIboLqOZypKjEARSbKDGGLTBKxomKafOtJLdtaUq5kzDIMbwkdaNr4Qa4FnTIEGrVPL7fvpydSBtT/C1JPBG0FqgAbouzls 6oszskjr VdsHqtj4j/+c3hk5LMhLIPkGXJt46YjJPDLmLa28MaTlT16to3SiQBaWNJwN8khVZzirCutc+M5JngjbfMa8a05Fyz2orJhVPcx6WIiaLxKz3br1RaPhQJgJO12ums6LEBnQeVzmeymMPvy5K7Am3Pw4lId53K3rhTaSDcwB/DzKyqOl+WE8749OU9rU6XctIHZ498xNt9ED52y7UVSdS1ZRTeiJ5CSiqZzF2HDqkoMLTzpTcju6EI/3OLaRtUTbLxTk3ADsQQYYrvkp0llOZtwqcCNA5w9ES03tbrxPMM4I12V1uS7KSXnJFHMKnwFXmp17h+9EZdQpDQanVrbTWnaqk3r7wSIrYnk2vJaKls3u4jCKhMPtTbexvnP6emjtJC9fgFFG8WnnUEajWL0qR1gmz5mEvTZxfZ9wjzE3tRg15uwIlA0ir9txsQSAeDZVyJ29rKqenytY8n0N4nhYOQcuen3LgE+DACS0ez+GKj5fDNxpb4wlI44mfPlv25ATyPEY6P5vDYZnfrs+jcK33G7pNRuXnupdoahgq X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, May 15, 2025 at 08:55:47AM -0700, Andrii Nakryiko wrote: > On Thu, May 15, 2025 at 8:53 AM Kees Cook wrote: > > > > On Thu, May 15, 2025 at 08:47:47AM -0700, Kees Cook wrote: > > > On Thu, May 15, 2025 at 09:12:25PM +0800, Shung-Hsi Yu wrote: > > > > Bisect was done by Pawan and got to commit a0309faf1cb0 "mm: vmalloc: > > > > support more granular vrealloc() sizing"[2]. To further zoom in the > > > > > > Can you try this patch? It's a clear bug fix, but if it doesn't improve > > > things, I have another idea to rearrange the memset. > > > > Here's the patch (on top of the prior one) that relocates the memset: > > > > > > From 0bc71b78603500705aca77f82de8ed1fc595c4c3 Mon Sep 17 00:00:00 2001 > > From: Kees Cook > > Date: Thu, 15 May 2025 08:48:24 -0700 > > Subject: [PATCH] mm: vmalloc: Only zero-init on vrealloc shrink > > > > The common case is to grow reallocations, and since init_on_alloc will > > have already zeroed the whole allocation, we only need to zero when > > shrinking the allocation. > > > > Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing") > > Signed-off-by: Kees Cook > > --- > > Cc: Andrew Morton > > Cc: Uladzislau Rezki > > Cc: > > --- > > mm/vmalloc.c | 12 +++++++----- > > 1 file changed, 7 insertions(+), 5 deletions(-) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 74bd00fd734d..83bedb1559ac 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -4093,8 +4093,8 @@ void *vrealloc_noprof(const void *p, size_t size, gfp_t flags) > > * would be a good heuristic for when to shrink the vm_area? > > */ > > if (size <= old_size) { > > - /* Zero out "freed" memory. */ > > - if (want_init_on_free()) > > + /* Zero out "freed" memory, potentially for future realloc. */ > > + if (want_init_on_free() || want_init_on_alloc(flags)) > > memset((void *)p + size, 0, old_size - size); > > vm->requested_size = size; > > kasan_poison_vmalloc(p + size, old_size - size); > > @@ -4107,9 +4107,11 @@ void *vrealloc_noprof(const void *p, size_t size, gfp_t flags) > > if (size <= alloced_size) { > > kasan_unpoison_vmalloc(p + old_size, size - old_size, > > KASAN_VMALLOC_PROT_NORMAL); > > - /* Zero out "alloced" memory. */ > > - if (want_init_on_alloc(flags)) > > - memset((void *)p + old_size, 0, size - old_size); > > + /* > > + * No need to zero memory here, as unused memory will have > > + * already been zeroed at initial allocation time or during > > + * realloc shrink time. > > + */ > > vm->requested_size = size; > > This vm->requested_size change you are adding should also fix the > kasan issue reported by syzbot ([0]). > > [0] https://lore.kernel.org/bpf/68213ddf.050a0220.f2294.0045.GAE@google.com/ Yes, this looks very much like the kasan oops that motivated the initial patch: https://lore.kernel.org/all/20250408192503.6149a816@outsider.home/ -- Kees Cook