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 6C385EE14C3 for ; Wed, 6 Sep 2023 21:37:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6A43280020; Wed, 6 Sep 2023 17:37:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF1618D0005; Wed, 6 Sep 2023 17:37:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 992C2280020; Wed, 6 Sep 2023 17:37:50 -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 80CEC8D0005 for ; Wed, 6 Sep 2023 17:37:50 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5139F1CAC89 for ; Wed, 6 Sep 2023 21:37:50 +0000 (UTC) X-FDA: 81207485100.27.6A8E06B Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf17.hostedemail.com (Postfix) with ESMTP id 840A840009 for ; Wed, 6 Sep 2023 21:37:47 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694036267; a=rsa-sha256; cv=none; b=zPBYTXzYXQIAvq2Gz2gFYcA6Mjjx0QSetrOYO3F78uzCBbdEp7Y2/K/bfxTV1sFxx3i98m iwVjOax1nht8Lrx7eZfNv9hDHTA3qENfZX+i5PPUUiKTc0X7nV/kN+xPRh/efkTETgxZ23 9hhl747yuFE6DIbicLwvkCNjSAidbao= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694036267; 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; bh=CT+AsghfKZwEMBTNB0CQ+1C872qx/oI8Jwb/u5m6V1k=; b=WgQBRkrK+xtRbYH8NmquNnfrZLiw/gqCfgMqryGB6rjtxDex791s+7HDHglMxsHJLd6EEG 7nbobqBZRfNOZn3qxEHyGRiQbFlysPrTFfH4ntxk52ISf1UYvBfWDxtBC3bh1kjWAA17G5 fJ87St+fpwbrLkpnyDivrp7mQ4PRsQw= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C51D3B81CA8; Wed, 6 Sep 2023 21:37:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24DDFC433C7; Wed, 6 Sep 2023 21:37:43 +0000 (UTC) Date: Wed, 6 Sep 2023 22:37:40 +0100 From: Catalin Marinas To: "Paul E. McKenney" Cc: Joel Fernandes , Christoph Paasch , Andrew Morton , linux-mm@kvack.org, MPTCP Upstream , rcu@vger.kernel.org Subject: Re: kmemleak handling of kfree_rcu Message-ID: References: <20230905111725.GA3737639@google.com> <20230906143529.GB1127143@google.com> <24f3d4fc-56c0-46bd-8e5b-af57f09fa777@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24f3d4fc-56c0-46bd-8e5b-af57f09fa777@paulmck-laptop> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 840A840009 X-Stat-Signature: jao464zobmq58788fy36xs9xsbspg5gf X-HE-Tag: 1694036267-288440 X-HE-Meta: U2FsdGVkX18GIkZW+vcMN/eT8/JFg30RL418qjumsahLX6nfATDP4Nrrc87fGDmQUAkWa7/5zuRvsVw/G9p7gLYzO2moqnKCvVXp0Dl46ccGQoVS/pSPgBYGM6x9KQjPW4TxUMeQnNScgCi3dSuvKdiQH2aArCJuLKXmcji/fH6kEOdkUNfY5+uaReW4N5oaIB84cvqGUN5akqQZo85iCPrYyj0fB6s1CKsDLZ0N+2OCI3cXJAZmLI7ILGw5UE4P6S8Pu/IOZDy2Dd5GHpJGrxQEDlnvR8ljL8OVrCvNZYQd7pxiOJmamDqVpmI+c3vCX2eKqGErq7fBZc/GQVB/viFxnXwhdMuN/jOEVeFeqjisYJ/Fyh6fWQnHyQqUfDtx4oXyD1nri+EJrWIRxF4PxRbyZ/fv7kd9+augeE8rMenr9aFTKvPv5lnG87UdBh5RPUMHE+nOicZOkcB12ddslxcuaBZeauCDgqRQB5M5g6tDnOTaOgPci93SmFSmU1TQN9UJ4En5YrEhWm0sNmD0s0X5W7r29iWj8vyT9+3paExWjiTcoF+T3Qhjupa3Qdyzmi9Fm16/kYkDxWCLo27y9G9jNDSuaGPbaSzq8N3pcWlnxGDCdnke9JOQ09g8K+gHZzrY+vNXpMpP+A4vw7YgHuv1pVZPRiN2VuNSjXnS/Z7RC7sJ023IMrLgFH6Nbxpdm1QKhSY1G8gQ+hwXBJRp1m+ctB0aSlxKFCuZ0s4cOShUbC3lOH5ZA71Vgt8sfz0JS1Q7T/rYhf3PjcCvNGcmIaYpXWf1lN/Aveudm2UDofKlmHIYY9/dxGD3f9Gl/YEzJQ4EwFMeKAyF12NopbvigHC0fGP+Dctk98GJyJaKt1WpEP3/1/NaI02bZrwhD4De5zP4IO4kcBUjF0jXt85cfWvtzM5VnVfBP0QjeGMbYxRFUkp9kXL6dh+9gGlqbMzQCbz57b23l7an3il1J5M saL4RXg7 JnwFjnjURbUFEuyj3BgIcct1sp4IPOX8aTdvxE35+vbO7NBqvW62xCIshsAuMaDaL5OWQEG0BkhFjlz7+SM8RKueZ5FkyeRUgVyPSDw0txtj+BZ2fdPoJb9CtnJqfjyxbxe2iNKeQilTq9n+axdRhRaeCthgURWFy4lYE9SJxi1YZQXHcXWrqOGlEb7im/fl5HL6mSkXOs4xgp7SinAZVAuKFJq2Sxjb2A7AGcX2mKqygtBAxzhFv+Yr5JvxPxctPON+SLdFxIV4jWLrPQwGyC8XBmR7sdi8oaXSYFzBSBUjWcF0ro7oflg0dgb2nkH7wE7F0qNHa9l3TjC2Z622VURN/uAuq4EQZ1tCtllTVTIZWS6Bk31JLI5OsQ/OnZnykcMNZwLUEhm6EXZnJF2zEfofgAs23mfvYe188JFi9liRrvk0fmICqEjFbVsMqkIM2kKWDpyeSjbSduwv3Oum7q60H1w== 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: On Wed, Sep 06, 2023 at 12:11:12PM -0700, Paul E. McKenney wrote: > On Wed, Sep 06, 2023 at 06:15:49PM +0100, Catalin Marinas wrote: > > On Wed, Sep 06, 2023 at 02:35:29PM +0000, Joel Fernandes wrote: > > > On Tue, Sep 05, 2023 at 03:41:32PM +0100, Catalin Marinas wrote: > > > > On Tue, Sep 05, 2023 at 11:17:25AM +0000, Joel Fernandes wrote: > > > > > The correct fix then should probably be to mark the object as > > > > > kmemleak_not_leak() until a grace period elapses. This will cause the object > > > > > to not be reported but still be scanned until eventually the lower layers > > > > > will remove the object from kmemleak-tracking after the grace period. Per the > > > > > docs also, that API is used to prevent false-positives. > > > > > > > > This should work as well but I'd use kmemleak_ignore() instead of > > > > kmemleak_not_leak(). The former, apart from masking the false positive, > > > > also tells kmemleak not to scan the object. After a kvfree_rcu(), the > > > > object shouldn't have any valid references to other objects, so not > > > > worth scanning. > > > > > > Yes I am also OK with that, however to me I consider the object as alive as > > > long as the grace period does not end. But I agree with you and it may not be > > > worth tracking them or scanning them. > > > > I guess from an RCU perspective, the object is still alive. From the > > kvfree_rcu() caller perspective though, it can disappear at any point > > after the grace period, so it shouldn't rely on its content being valid > > and referencing other objects (other than transiently e.g. in RCU list > > traversal). > > > > It probably only matters if we have some very long grace periods (I'm > > not up to date with the recent RCU developments). In such cases, the > > object still being scanned could introduce false negatives. That's my > > reasoning for suggesting kmemleak_ignore() rather than > > kmemleak_not_leak(). > > Very long RCU readers still result in very long RCU grace periods. And, > after some tens of seconds, RCU CPU stall warnings. So don't let your > RCU readers run for that long. But you knew that already. ;-) That's still ok. I was more thinking of deferred freeing well past the RCU readers completing. > > @@ -3388,6 +3389,14 @@ void kvfree_call_rcu(struct rcu_head *head, void *ptr) > > success = true; > > } > > > > + /* > > + * The kvfree_rcu() caller considers the pointer freed at this point > > + * and likely removes any references to it. Since the the actual slab > > + * freeing (and kmemleak_free()) is deferred, tell kmemleak to ignore > > + * this object (no scanning or false positives reporting). > > + */ > > + kmemleak_ignore(ptr); > > Do we want to un-ignore it at the end of the grace period? Or will that > happen automatically when it is passed to kfree()? (My guess is that > the answer to both questions is "yes", but I figured that I should ask.) No need to un-ignore. This function only tells kmemleak it's not a leak and doesn't have any interesting data to scan. Kmemleak still keeps track of it until properly freed. -- Catalin