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 5A2FEC71153 for ; Mon, 4 Sep 2023 21:23:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81CD98E0017; Mon, 4 Sep 2023 17:23:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CD0F8E0009; Mon, 4 Sep 2023 17:23:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 694878E0017; Mon, 4 Sep 2023 17:23:04 -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 58B078E0009 for ; Mon, 4 Sep 2023 17:23:04 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 58E8B1206A9 for ; Mon, 4 Sep 2023 21:23:03 +0000 (UTC) X-FDA: 81200190246.10.36DDAE6 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id A10684001E for ; Mon, 4 Sep 2023 21:23:01 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf27.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693862581; 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=ktPJeQB+oNC8gj1dcMDcxIjidfcAD1e7eTq02h4jQXY=; b=ZqqlIctM3RWG5yQ0YYVu9FF98/zEThaifeGccS2InsFaT2EGr+bjvqrV8TvEtMrDSyxyrc FEgXes+y3g93fz2RlJmrVoYtzy19TmP1VM9OmeTd6IGJkaXoNqxmlE55UzqLryd5Zq4phP 4keGdlfjFqAB3MsB2tIQd5VAytH32dw= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf27.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693862581; a=rsa-sha256; cv=none; b=aS+akvYxjRAJDELMZeOf9M8XB4pAphB4x4FarKBPamimGu/qmBa4RN55/Ckq5H2pFslL9Y hxWFaCbHMgoB0paNoBpkx8A9aln3IJ83Y/5YB5HsbNPTEQ0nIaSOGB2+jKOr9KpkGJ48eE XuuZ2BdGbtLR+mQ+aKqCaeB7cyDuypQ= 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) server-digest SHA256) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 96B3B61188; Mon, 4 Sep 2023 21:23:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD244C433C7; Mon, 4 Sep 2023 21:22:58 +0000 (UTC) Date: Mon, 4 Sep 2023 22:22:56 +0100 From: Catalin Marinas To: Christoph Paasch Cc: Andrew Morton , linux-mm@kvack.org, MPTCP Upstream , rcu@vger.kernel.org Subject: Re: kmemleak handling of kfree_rcu Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: t9n3or4rdzy3zar16wnah9qfrgsqhkyh X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A10684001E X-HE-Tag: 1693862581-227566 X-HE-Meta: U2FsdGVkX18RD0fyPus+0aDDTAwSgi1FjcvmH/QG1PpdMhDzq5yB+D7peA8cuzHOGl8ut40flDVxhUK9GstYoTn4CyY5URSZGRPeHDDXsOIO19BhH4/RLRBq4/sFdoMCcuGyWedFcHu2a/7SbiYr94L7puF7v56xyRLWjuMmcwDnQgpZZxZfwbtqwQ6P4iN/7m21vBE86cgrQRKB+9Xjubqx6LJo/kp+MP594twvXnEB/HszoIH8x4kOHilfh5ajAPXPOz3yCdS3G4DuMzda14kzhDw1RulGcZv0T3rFYQPNQdy+AP+nrQFWrpxhPQkT0TIgUCXiPdJR6vhxrBS95MHkOKGMBZRa3TldAhM0ezNB0HBiXJnYBTK+wDK/fGcnRhZuBAZDVjPm/qdxthwVjoPvkGMuUPKKFsekgw0RM7pdBgOgTCws9nckMOOfoh5isoD3ilOTy6YgtAGDKab2oM4a1Ia36u/FYTjO+N7NKmglHPGVl/JoM4AxY33oCLrliWQU9DnF/v2+ikUWHx9kkOSovC9FfmL9JLi0iMewJbl1DvmXcffn+rbPVDdGDaOjKpUe2BnXWoyNdMQO7Lx/jNMVQUjEn6DdMbNz2td76FI3JT3p2wyJew5ZpCOz5jzWcD8GXhFw8UCym8UVnyM0e0DpgQWODB89lIMaTVfErEa3+K31/YLWYTUsHmusDtGJO+hR/emgEQd8pp1oEBi3sRwZo0a1Gzx1N9e0ORrWSXvuttECDkVnSqlwMDpUUxSN10uH87Cmslr0eY+sQvliGmpFcGxR68LWKPURF1RrebiR2Dq61Wq9GpptqvifP/nwmTWiPyUSTb9JtJB6ROAhm5tIzLj2hcPqoKE1HrwHyuVuKPoxtBy+Ud/ZH9lc3GAe5f1cPG8Xq+WQVr/E0Db732Gb/qn/aZcOQ7xKOMueRueQRugisnqZcI+QDa8Ehflu/Pwg4a1d4/Fnoryjj6D NQKFzK/+ t9HWMX/PUdtBjDS/ASEpc7wgO4RzJsf5kw9B+4djHI+appFWTsXDT33aMc45qi5q1QykPfKfjdSQUoBj01euFpehbRWlz3EH94BQjXlmp40Y6EZ+07/UENO5N16oqvvI77hfEPerWWp83Qs+uCM/4ZNPk4nle4+ik7QhtvZ7leE6Mee/M2I/KKd6xX6Wr/2ThfG0k/Sdic8TRZamsFvzhV32VYKaGXEJ5cXod7YE4P7o1WCcfRW1ka7op+upGJk21fyM3/Fo1VftzQdCbNHPocvLZUIX3Bk0Ncvw5LwYN+8jogifJUMHHaW54gGu+Jl8uAcZ8gASMuIZ+0ocJ7WSzJWXk1latdFjt+mkC+Ua7UJZ13lp44KmzoXNQzOIInfWpxlPOeUE7tlVu0C7jIpTuTT9ojIvdAaOGE1OmU1W04UNjaIs2Xjo/n3xK4vR/w4fZiGfpgxmEncrpQYMH5C+KNdobZNtO2uskbFQnwx5AUK30sy+H7yw3BrB9dzoifKE438Cbu410cippuTs= 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: Hi Christoph, Please try not to send html, many servers block such emails. Also adding the RCU list. On Wed, Aug 30, 2023 at 09:37:23AM -0700, Christoph Paasch wrote: > for the MPTCP upstream project, we are running syzkaller [1] continuously to > qualify our kernel changes. > > We found one issue with kmemleak and its handling of kfree_rcu. > > Specifically, it looks like kmemleak falsely reports memory-leaks when the > object is being freed by kfree_rcu after a certain grace-period. > > For example, https://github.com/multipath-tcp/mptcp_net-next/issues/398# > issuecomment-1584819482 shows how the syzkaller program reliably produces a > kmemleak report, although the object is not leaked (we confirmed that by simply > increasing MSECS_MIN_AGE to something larger than the grace-period). Not sure which RCU variant you are using but most likely the false positives are caused by the original reference to the object being lost and the pointer added to a new location that kmemleak does not track (e.g. bnode->records[] in the tree-based variant). A quick attempt (untested, not even compiled): diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 1449cb69a0e0..681a1eb7560a 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -53,6 +53,7 @@ #include #include #include +#include #include #include #include @@ -2934,6 +2935,7 @@ drain_page_cache(struct kfree_rcu_cpu *krcp) llist_for_each_safe(pos, n, page_list) { free_page((unsigned long)pos); + kmemleak_free(pos); freed++; } @@ -2962,8 +2964,16 @@ kvfree_rcu_bulk(struct kfree_rcu_cpu *krcp, rcu_state.name, bnode->records[i], 0); vfree(bnode->records[i]); + /* avoid false negatives */ + kmemleak_erase(&bnode->records[i]); } } + /* + * Avoid kmemleak false negatives when such pointers are later + * re-allocated. + */ + for (i = 0; i < bnode->nr_records; i++) + kmemleak_erase(&bnode->records[i]); rcu_lock_release(&rcu_callback_map); } @@ -2972,8 +2982,10 @@ kvfree_rcu_bulk(struct kfree_rcu_cpu *krcp, bnode = NULL; raw_spin_unlock_irqrestore(&krcp->lock, flags); - if (bnode) + if (bnode) { free_page((unsigned long) bnode); + kmemleak_free(bnode); + } cond_resched_tasks_rcu_qs(); } @@ -3241,6 +3253,12 @@ static void fill_page_cache_func(struct work_struct *work) free_page((unsigned long) bnode); break; } + + /* + * Scan the bnode->records[] array until the objects are + * actually freed. + */ + kmemleak_alloc(bnode, PAGE_SIZE, 0, GFP_KERNEL); } atomic_set(&krcp->work_in_progress, 0); @@ -3308,6 +3326,11 @@ add_ptr_to_bulk_krc_lock(struct kfree_rcu_cpu **krcp, // scenarios. bnode = (struct kvfree_rcu_bulk_data *) __get_free_page(GFP_KERNEL | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN); + /* + * Scan the bnode->records[] array until the objects are + * actually freed. + */ + kmemleak_alloc(bnode, PAGE_SIZE, 0, GFP_KERNEL); raw_spin_lock_irqsave(&(*krcp)->lock, *flags); } -- Catalin