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 B116BC8303C for ; Tue, 8 Jul 2025 08:13:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE9C16B00AC; Tue, 8 Jul 2025 04:13:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC1BC6B00AF; Tue, 8 Jul 2025 04:13:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB1058D0001; Tue, 8 Jul 2025 04:13:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BA0956B00AC for ; Tue, 8 Jul 2025 04:13:17 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6D60C10B246 for ; Tue, 8 Jul 2025 08:13:17 +0000 (UTC) X-FDA: 83640382434.11.162497D Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf29.hostedemail.com (Postfix) with ESMTP id BA059120002 for ; Tue, 8 Jul 2025 08:13:15 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=RwGqV6tf; spf=pass (imf29.hostedemail.com: domain of rppt@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751962395; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jqcPbQl7SBXMytMXEucTFV/X80S3Jz+r6fPoAa61QFk=; b=yl3K8pAvoR1MWOJim5peoEu1QynzzJcNWMmQXwBSG9ZGRW+dRwXYKcKB/ncEFZI2+KYVYa ZOpdjzMmtvrOCsaG4hb76nLEbd3ONspH75e3vhfdpydzmw1sGqt/OX2fG2pKVWlpn2vhCV RlBzgZVEiUQ2VXubfGPItVt62a7IlA8= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=RwGqV6tf; spf=pass (imf29.hostedemail.com: domain of rppt@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751962395; a=rsa-sha256; cv=none; b=knCRFZPjqamwwKwyDDhxQxXCunGmoeXOZAvar7RTsmwVo9QZwvQxab6JzNS56GJZpV1IVt iYDhlpcRDobY6kxp698zN3jlmY00MADSNYYMTSjmzhbRecJ2BYPaj8a77r74vLLVczlD/M wO4sF76DhZDfN8U0OC+D8+CK90kKAxk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 1CA6FA52DEF; Tue, 8 Jul 2025 08:13:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5BA29C4CEED; Tue, 8 Jul 2025 08:13:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751962394; bh=aYotaDQsTWKZrcKVAgzWOgtQh4U9sufr1mwzUzZ3AWI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RwGqV6tfK3KqGqoZ+FGPc5T58orUwoWtR/bQB+rla9vlXVzyWp7Vtt8iM/9VraGQG b/M+qCtY7XRbPfYjE3pK+W+PAf7Dvb6UWbhVO5J/giW6rCNXfj6xKTxe5hxDu8PGGc M/RPuPcg4GfLfrZGik+xpOVhuF6B4OfU9IiHT6XcpduJM96Foftkop6l1ox4XPF9Uw mr1AKcIvq1LyqytMIeX/44wvG7EIRfISMK7002sFVtz1XMxmEPkz/1nx8SJTRxmp51 yQoe6+gXqCPcgaXq+AhJJV1ZdYxFZpQh+DojSa9S9A0VRvOtxjLjAlS42bNf1aQa4D reUxEA16sPoQA== Date: Tue, 8 Jul 2025 11:13:04 +0300 From: Mike Rapoport To: Peter Zijlstra Cc: "Liam R. Howlett" , Andrew Morton , Andy Lutomirski , Borislav Petkov , Daniel Gomez , Dave Hansen , Ingo Molnar , Luis Chamberlain , Mark Rutland , Masami Hiramatsu , "H. Peter Anvin" , Petr Pavlu , Sami Tolvanen , Steven Rostedt , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, linux-trace-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH 3/8] execmem: rework execmem_cache_free() Message-ID: References: <20250704134943.3524829-1-rppt@kernel.org> <20250704134943.3524829-4-rppt@kernel.org> <20250707111102.GF1613200@noisy.programming.kicks-ass.net> <20250708072649.GC1613376@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250708072649.GC1613376@noisy.programming.kicks-ass.net> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: BA059120002 X-Rspam-User: X-Stat-Signature: w4oreprqitksdr4wyooibt1gg6m64s38 X-HE-Tag: 1751962395-233847 X-HE-Meta: U2FsdGVkX1+LRA5pCBEqjyUsg6r1czzWumJlcm6/wD/XHabWnJFHqMFaJsgg9OmtDWlumHWRL7GgDT+/eaCeLqWs38wZ8XCNZj4bs+L0wCdSHExszYVQsDrhdduejexut5wFI7pd0LhhpmmfvEGjjzD7KCOBber34nPNWkxq1l581dHqVuuVeurak9MKwsdaI3HD2ASAigccf+w2m38SZ/i8zDUnjb5axYFpdUnvxxCXOEKeduWC1+nyq915+p92gAszseHXigo+SESvVA4IrghuPI2V5GnCHFmbafL3OjHepnZ4goRPLYz0yP7wN124qxydQV+zgy4KcGl2NTsy5iIsOKWCQXmk0eFttlB4VP87QGflp3FmgHz6h3NlcTq7wzpSqtRd34u97bpRViziataP12YNKWgjasE1CDuI2ggpSEviezb6KOZOsepC6Gvy/iZ7f/xwAeiW8Uf+AYeK7fmx+jqLNSPM5B8CADM/iC0I0AyKJielyPhfsaTQxBb04NB2LRbCz/bLJO0g61zBYTHz1wtFlij0EJxwf7lLfjFDY1r41HuKYnlmQ+WVMhZuCDB5ejQptnILpmkWUOmlXaT1pw1TsnD0Iy/V0ft2EDnF1u+ZS3O9GqFTRNMYkYT989vrb0kyi8C9c2lctbQQZl9C/DKOZG20RnUbc5BJM3+Nl7E3xM3aqwor3+xpkcaQG+0WBfeGsHBY0NPBZ7vd7k+34o7jGqanZ5Ws9WrQMy6TGAZpQkJVpkoLgbcRE/2dqrOvhx6pvPd80CMsjtitjz+b3aFXGk321nlctvGdW1rXStxoXuu3bakXnSBJZ//35EorWJCCO36n4GYf8RI9Np/sVv6BhlPJpfKQijh30b2GCjmbeLV8a9LjzfqP8Sy8+RHCe2Aa6DGW/UBz85niq0w/VFsOAy4GHvwwqw2/jj/FtiFpMAypCgpQ0pTaFqDQCjT3nod/BSL1VtUvQ8W vmBIXj7x E+TB0oO+ogOrLpSS2nOnwtkudnoF1eK0A83Doxc5ApW1von5uCyfaNotoJgWZu2itmCspQrhXkEUTLQ+gRa4NjgsGlQnjGqoeSD/dHKP5sCF0yVCLwBxroM6QkF5pv5lp+34QSeCdhh4+vXN/LQkqgBZBneKmNgioV9WKRnPQlubEfERM4nZP6t9orL59S4Fgs+zNf/JSAQuo9LBcQIgxVYAT2B3fc8zzJgFqjsIK9BzbcdkwpsJdOS2eIst4W+CkzzGiGFv3Uys0MXvn2Z0mWXxvj/TXfnRvvdRq7NNQ3dX8pHdqOSh4AyAmWfH5pbtZJQqi 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 Tue, Jul 08, 2025 at 09:26:49AM +0200, Peter Zijlstra wrote: > On Mon, Jul 07, 2025 at 06:12:26PM +0300, Mike Rapoport wrote: > > On Mon, Jul 07, 2025 at 11:06:25AM -0400, Liam R. Howlett wrote: > > > * Mike Rapoport [250707 07:32]: > > > > On Mon, Jul 07, 2025 at 01:11:02PM +0200, Peter Zijlstra wrote: > > > > > > > > > > err = __execmem_cache_free(&mas, ptr, GFP_KERNEL | __GFP_NORETRY); > > > > > if (err) { > > > > > mas_store_gfp(&mas, pending_free_set(ptr), GFP_KERNEL); > > > > > execmem_cache.pending_free_cnt++; > > > > > schedule_delayed_work(&execmem_cache_free_work, FREE_DELAY); > > > > > return true; > > > > > } > > > > > > > > > > schedule_work(&execmem_cache_clean_work); > > > > > return true; > > > > > } > > > > > > > > > > And now I have to ask what happens if mas_store_gfp() returns an error? > > > > > > > > AFAIU it won't. mas points to exact slot we've got the area from, nothing else > > > > can modify the tree because of the mutex, so that mas_store_gfp() > > > > essentially updates the value at an existing entry. > > > > > > > > I'll add a comment about it. > > > > > > > > Added @Liam to make sure I'm not saying nonsense :) > > > > > > > > > > Yes, if there is already a node with a value with the same range, there > > > will be no allocations that will happen, so it'll just change the > > > pointer for you. This is a slot store operation. > > > > > > But, if it's possible to have no entries (an empty tree, or a single > > > value at 0), you will most likely allocate a node to store it, which is > > > 256B. > > > > > > I don't think this is a concern in this particular case though as you > > > are searching for an entry and storing, so it needs to exist. So > > > really, the only scenario here is if you store 1 - ULONG_MAX (without > > > having expanded a root node) or 0 - ULONG_MAX, and that seems invalid. > > > > Thanks for clarification, Liam! > > The tree cannot be empty at that point and if it has a single value, it > > won't be at 0, I'm quite sure no architecture has execmem areas at 0. > > Would it make sense to have something like GFP_NO_ALLOC to pass to > functions like this where we know it won't actually allocate -- and > which when it does reach the allocator generates a WARN and returns NULL > ? We can add a WARN at the caller as well, that won't require a new gfp flag. The question is how to recover if such thing happen, I don't really see what execmem can do here if mas_store_gfp() returns an error :/ -- Sincerely yours, Mike.