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 186FAC3DA4A for ; Mon, 5 Aug 2024 11:25:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6042A6B0082; Mon, 5 Aug 2024 07:25:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B2F66B008A; Mon, 5 Aug 2024 07:25:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A2E56B0092; Mon, 5 Aug 2024 07:25:07 -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 2D5A76B008A for ; Mon, 5 Aug 2024 07:25:07 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DBCC1C0232 for ; Mon, 5 Aug 2024 11:25:06 +0000 (UTC) X-FDA: 82417960212.08.F2F1761 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf04.hostedemail.com (Postfix) with ESMTP id F40194000F for ; Mon, 5 Aug 2024 11:25:04 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fkhEnFvV; spf=pass (imf04.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722857044; 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=gFXMf3R67uSoKvDTRLMWNYmM8RYGM52hCNv8M1S6BK0=; b=7YoX6VSWKSewiTAhh1vQFhi29V0shHSJYNlSpOnq6rOsDCssNRCabE26oBe8ZOtnf3LUH/ sWoq9D2sOTHVbjopZ/1tpYityPRPqqiZMEsaEY3tvAWD1dHDG6qkySeyFzEH+8TAPLseGB No5j1YWSkCjqLPIgmvvIPoGqOxTYmeM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722857044; a=rsa-sha256; cv=none; b=sf+fTFoU3qwKO9CQ4g2OZ6cWB0tEWY+e6M1mnoNO2MI9L3y6Ei/7WOB1oKMEAvvutQT+Re QzY46TcDvn59NojRkbXuI8zjD+TMaM54FO5Lejtngyqt2+kVVfH554HuslKACqExXrIEVL sPIjTa/z94LhK7JtgpiMDihWlQOyIds= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fkhEnFvV; spf=pass (imf04.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-5bb85e90ad5so723773a12.3 for ; Mon, 05 Aug 2024 04:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722857103; x=1723461903; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=gFXMf3R67uSoKvDTRLMWNYmM8RYGM52hCNv8M1S6BK0=; b=fkhEnFvViPLk1aAK46wHWsT/kwuREhGRe18Q2iM75U0wMKXWuXt67TlfJ3scOum+Bc xDMBOO0+lYZRtdP6ZKpTAemH/Hg6yzeu2SiSeIbwPkQvSqDnR7fQWGiJieKpZ76M2tLK Y9WEzWNfjn4DiFYm8IT9QfurRytxpX9ZqypyKFH2pvWIWEGKXHLHnYU8s+S0zwGcSxxN kxgEdFk67uTD7Vrdj0ZvfVdpAca1GULHZF8KaARptVZDYnIR1QLsTBlQOZAg0gFQnNqt 5BNIqK3wA0Y1Ur3bht7KIWQ0H04oF9YASyH6zVnXFRDToiq/Fmt6igfxP0b0bgZqk4I3 ZcUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722857103; x=1723461903; 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 :message-id:reply-to; bh=gFXMf3R67uSoKvDTRLMWNYmM8RYGM52hCNv8M1S6BK0=; b=CV5qHYHuwH9pgb4XQ1LQC41mwNoHuZfxSlXfkRUPka4Kwq4PA92Joo0gtp6nB0WfqZ RfN0gDh36pnqSwFVAQ8O+xfIrMCpQtcBWaZ/K+s7NPvDnDsvyRsBmCj/3ilBERGZAI83 EUW1XWMOkwX6P/Dx1Rm+vEqf+1s4564cRjCJ9vrGRmmIAy+8YN9Co3w6zfe6bi9osgdn DTMO83018v5A3/JOA20InR+g9a9m52TTDxu6kgw3GQeBhxqUJ5I3bC/1PXg/n3odasOb nutjhNQJWtbDBoppF3AyB3hbEtyk/+APSlvH7IvgqMcrxtbSiDr2Kfpt4PvUQheBawRN 9WeQ== X-Forwarded-Encrypted: i=1; AJvYcCV53wYUGau9KWwEx76L+LZKqQlRioLRppAWtZzp/Nf4fFHt1+bfor2XTCrKxMVauOlDrQVJNAJoaVGxfuqrdPwpW70= X-Gm-Message-State: AOJu0YwvpGyrU4QfPpqFxEjMcdTMzYvsBcXFKIteKtRlvcBGa86HrvRw J/w2P3ON9dHIIuMkpaDaiuJQ7h0zlR/NuJQZpzncwP+be11Wna/N X-Google-Smtp-Source: AGHT+IGl8zJrqXM61TCZr9PNc5KrvF91rHZl3Bz/6P2UyX7/YL/NskRppOIpo9ppHmlXkpyGCOKB0A== X-Received: by 2002:a05:6402:a42:b0:5a2:cc1c:4cf0 with SMTP id 4fb4d7f45d1cf-5b7f36f59ffmr8021608a12.7.1722857103095; Mon, 05 Aug 2024 04:25:03 -0700 (PDT) Received: from f (cst-prg-90-207.cust.vodafone.cz. [46.135.90.207]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5b83a14ea04sm4789153a12.49.2024.08.05.04.24.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Aug 2024 04:25:02 -0700 (PDT) Date: Mon, 5 Aug 2024 13:24:49 +0200 From: Mateusz Guzik To: Vlastimil Babka Cc: Pedro Falcato , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] slab: Error out on duplicate cache names when DEBUG_VM=y Message-ID: References: <20240804212839.685795-1-pedro.falcato@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: F40194000F X-Stat-Signature: uut7hqmo8hshar9yt8z7aj46p4upkr86 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1722857104-262030 X-HE-Meta: U2FsdGVkX1/UQrfpMAOhnNqlfw6VVgS7i3liLPJYXMAqwX2kZi89hI4BRstokFtL6RqMxNshEKHO+d9B94zF0v6nlfoLe+oZeYGW2h1cX7cFJMkUmBzXZq0ffTT38lG7owfA/9BaCfc+jXZcvv3b6Zse0r1qokbQACIBofvwNJBot0m8Nh9kMlJ7+ZMKi6V3Cr0mPiW8cbGO8Mex0ixlBYGHDswL0OovIprtIJT/6bdslHfqn5/Dv8xA/444x1hKpNeMRGLD70jqt/OJIwskuLhWttzno/HCNsbayOQbGJ1DlhFKjA2B/7Y3ZOEXvHs8GedgbmiGD5MH4lcX/AbN8nf4bqULTffNaw2G1/m9tsbRzE2ErqBREFH521DfrIvEh8fuJ8i3xTbEcF3ONwPUBi62BjWkbgpjXUFT8QHY7dV0pWm1W5i7bWFYFIKeAyEfdCklcbamA8dHmpx1BJnX2EojviZtDVXn1eO+KFK5O47DSJW23zEgogyljUIpbWQVFNyE80iOC4dCHnDoGFv5X5lMt8gTJu70g5jZERaBVIwey4VDTyrojy6S5wGaldfJWihw/EbXmCHV6YfKLICjNALc5YgF6nmZPn23FJKuZJbUEo8Zel1jLqyxX2cm0Ej+Tewki/FM8J8NRawcCk0DZqhUdAGr7sGi20LEnQ3zwEFAQFZUjixWbBYDlPrLEAKXAD0xZ3duTnm11OpKmEKaB/GZTb3tRotqYwn9e9SGLM+7RWfpEJlVnAYGDmp/1q8FkBChVofgslUndEYpcch+P2K6rm+/XYlIwnD3pHjtW4JFNoDxHPundZxrHKRpYOqciXQTrCcyfinbyVyAxLVnlsd2tmcH1vh6bm/gyl8zmcUVjrqNCTQ33mlFQFlw139i2+dVHURquLeTcmFc5JBWYOHDLFBV+J3rG2cKGmN/MItgRM5bvHjLy9pTZAzf4M5lI318fNJX603NAYYxdLV AA1AUmJH S56vnBq7C9Jsfd5t1XBIzVX/4OQ0MmaAWR0aRXvomp5m1SGO281lRcHh9fw5gsAt+knTxJIwcbwUNvt/5qUPpJqb07sodWhpCaOZ34M/1OebcSglSfvSZvpBaKD0Th/oEG+aVCmWUan3wiS+818k1yCJfFM8BeZWrgoBHy0rGCaY6lp0vKYUJeS4+Awtc9NhqYBQtvaRNXstHF/x645OULz8HhRU561u7UQVNXtCWO3s8LS6rPWGQGUloAhZAfR0uPPkK1OPYJw5zYZjeShoZjzKKfIQNM/jKhu1OrZg+8md9o1+KJGyhxlqj6UMlaso1m0Ee8VYB4YbxvFvuuuWBfF2RnKUWDHnkD6XM6YqVxIR89OtgFXcoVNnkB1yny3WcH3mi81RnrEaAfwoc550rwO0PQ6SqB31Zo70sNdno3kH03bS0A/YHQCb6w0zcfLW4rNyX4MdU8enphwKu5WJBnsQP3QVb+2jdUyIpzfXr8+mHYjQ= 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 Mon, Aug 05, 2024 at 12:38:29PM +0200, Vlastimil Babka wrote: > What about module unload/reload with a SLAB_TYPESAFE_BY_RCU cache that will > delay its freeing. Soon also if there are kfree_rcu()'s in flight. And the > zombie cache can stay also permamently around if it fails to be destroy > because some objects were not freed. > It should be an invariant that the cache is fully whacked by the time kmem_cache_destroy returns, at worst with the exception of when leaked items are encountered (but even then it should be renamed to something indicating it is defunct). Suppose a cache could not have been destroyed and was left as is, then the offending module was loaded again -- now you got two with the same name, which is not that great either. I find myself quite surprised that kmem_cache_destroy can return even if cache destruction is still pending. This was added in 657dc2f97220 ("slab: remove synchronous rcu_barrier() call in memcg cache release path"), citing batching benefits for frequent kmem cache creation/destruction. I believe the very notion of doing that *frequently* is b0rked and any code doing it should be patched to stop regardless. Even so, if there are any benefits to the committed patch, it perhaps can be augmented so that the kmem_cache_destroy caller can wait for the entire thing to finish (e.g., with a completion).