From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8644633CF2; Fri, 24 Nov 2023 19:17:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="IL09Kmlr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9CE8AC433C8; Fri, 24 Nov 2023 19:17:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1700853448; bh=hmiNFSWDyjG0d4KpbuHv7nHxryicqQhq0GGCG2/WiNo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IL09Kmlrsx+FOlX82IjvWow4TFBa6EWEIQaZrX/jZCc8qg/Fs8on2ntGZwTbP1O0k 1ryftSAR8bFkRxvCN2ajCPXcsttZRLZC1HkZQk20+qWHnofdlu8O4D2tFTIZDE+za3 Urhrwiqi0kFAWd8Ji5TaOUNxpsodFaMXzJvoFqws= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Catalin Marinas , Christoph Paasch , "Paul E. McKenney" , "Joel Fernandes (Google)" , Frederic Weisbecker Subject: [PATCH 5.15 193/297] rcu: kmemleak: Ignore kmemleak false positives when RCU-freeing objects Date: Fri, 24 Nov 2023 17:53:55 +0000 Message-ID: <20231124172006.979561566@linuxfoundation.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20231124172000.087816911@linuxfoundation.org> References: <20231124172000.087816911@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Catalin Marinas commit 5f98fd034ca6fd1ab8c91a3488968a0e9caaabf6 upstream. Since the actual slab freeing is deferred when calling kvfree_rcu(), so is the kmemleak_free() callback informing kmemleak of the object deletion. From the perspective of the kvfree_rcu() caller, the object is freed and it may remove any references to it. Since kmemleak does not scan RCU internal data storing the pointer, it will report such objects as leaks during the grace period. Tell kmemleak to ignore such objects on the kvfree_call_rcu() path. Note that the tiny RCU implementation does not have such issue since the objects can be tracked from the rcu_ctrlblk structure. Signed-off-by: Catalin Marinas Reported-by: Christoph Paasch Closes: https://lore.kernel.org/all/F903A825-F05F-4B77-A2B5-7356282FBA2C@apple.com/ Cc: Tested-by: Christoph Paasch Reviewed-by: Paul E. McKenney Signed-off-by: Joel Fernandes (Google) Signed-off-by: Frederic Weisbecker Signed-off-by: Greg Kroah-Hartman --- kernel/rcu/tree.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -3609,6 +3610,14 @@ void kvfree_call_rcu(struct rcu_head *he WRITE_ONCE(krcp->count, krcp->count + 1); + /* + * The kvfree_rcu() caller considers the pointer freed at this point + * and likely removes any references to it. Since the actual slab + * freeing (and kmemleak_free()) is deferred, tell kmemleak to ignore + * this object (no scanning or false positives reporting). + */ + kmemleak_ignore(ptr); + // Set timer to drain after KFREE_DRAIN_JIFFIES. if (rcu_scheduler_active == RCU_SCHEDULER_RUNNING && !krcp->monitor_todo) {