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 D982CEE14BB for ; Wed, 6 Sep 2023 17:21:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B30F8D0016; Wed, 6 Sep 2023 13:21:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4630C8D0005; Wed, 6 Sep 2023 13:21:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 352668D0016; Wed, 6 Sep 2023 13:21:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 24C7F8D0005 for ; Wed, 6 Sep 2023 13:21:57 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EA671B421B for ; Wed, 6 Sep 2023 17:21:56 +0000 (UTC) X-FDA: 81206840232.16.166FCDA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id 32A9F2000C for ; Wed, 6 Sep 2023 17:21:55 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf13.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=1694020915; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LnctrQYr+QVMLU3krWtCk0sHmbzruCkLeYEHnkiriIM=; b=8qEc38Z4YNuhOOB5TSFFhiaxWaxwN7hrj4Z/N6bxmCEVjOewhnyWa6YMvTwgWHdTkGiJ1T 1vwhWFLBeyocko5JCH7mIi98ZKoRnlUXEtE7AgH3IKpEByqdh1d0EHf7+T6AD0bncSmxwx HInm7ue5rm9vXCaeit5oIm1YJlHKPSs= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf13.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=1694020915; a=rsa-sha256; cv=none; b=6P/xIShpJuBL4N0RmqB35NuiS5m1wAfRp5WVaVLOsWt1mqZxNvz0pXHq6Q8DNdi5kV5w7n Ul175gJXWsu1lTmbhxnnip561UZ7cDmXjmfmGXLnUVIRgNkGrwpNFd1aJtSdVnwZOuiMBJ VzKc9+uRgvPwIQavtOFlP2gwnlH1Mc0= 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 dfw.source.kernel.org (Postfix) with ESMTPS id 2D4BC60F99; Wed, 6 Sep 2023 17:21:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 745D0C433C7; Wed, 6 Sep 2023 17:21:52 +0000 (UTC) Date: Wed, 6 Sep 2023 18:21:50 +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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 32A9F2000C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: immmygqc1ik159g1nrme9en5643mswmm X-HE-Tag: 1694020915-108478 X-HE-Meta: U2FsdGVkX1+2vgVGfDgb+bMgcmlLoXsf2wIFHNAtdHvoJmklb2ZmOalHDLtt8Acy+/j4A53DUBVflmuxOjgi/r9AGs7p6uw5D2EFNsNlDNChLS9h8E7vJQ/Lw/2mlrcKCHCpxyi5du6dt0F0ri3H3LsqCsRrUg8q8yyHkWKbZJATS1JhgXfXBe9u0HWbRpYI9uxyzY8implp4cSvh719++LPI91CANMCJey8HZPYtKPySMdJsCzq4IdcV5+JtgWveZeefqEic6HNmEXDjtz8nti2yeZUU8/Z0lq5btW8uwx0YIXQy6WYmn6s/M544MEelhNB7ryP49WAGCyXY6UyK1LPD6rGe+MpHxept1YeAHQ1p+JVJv6e6A7z2+zwO/jb4JA/LeXXpC7XOABycw16rGhAWb0o+lCiZqbmVTpTtd9p+Yb/IFO8dYCj8nB6oHLgS9SzXoQN7DvCOXt16sU8bjnwtInM9oikuMu/owH912wbxpQbPQoArE+4C6e+PDhytKzl2uAPruh0DkxxArZ29ZSVF5UpVmfMw3Q3zI4wJiC/dmfj2AGNzv9fuX/MhtKgJDPFDsd0JDuILoZne3QH5Bo6wqahmThklIlte++lW6DXxeF+9w5au1eTme+5zx0x0e10YTL5B32zozZguH2Fn+CEMQgeqXZrkqu+RJFZ1K6NkCSqm/KSCpys6Br30oeLoP83RPNPc0ZQqdwDa3gGHmzvkaTilrv2OMXEmdTLttXZXQc/zrD22+KBC6QxkRvCTqcEDN1QfiIEiBsb4r9yyOwIzjhMLxG/5YwJUQwK17P6swERs+MrO/A3gkfVaAP/LAWQLhlawDKj26RqLv6nYkzho2Dnakn6oOgv1MvQjSUj+BD6e807MxWmzigSUq/4saUKhvgOuelxg4RjZ/XJuLxBzJ91Y56FmwqTBBoZo0BGJw+iYMbA6fyP/zAM65WzkbUWfJPgG6sPqkyzQ7n lGxFiNWg XRojpLibQ1v2721BCmSzvUJwHg+iePueTiyPyPma94kypOHxhiB6h4Ok+d7NrJySPxNrCTcVO5L2wjhRp/LAN0O1ydqH5z+QKLdg9itSYHI/WX+SfYfs7EIE6xeaBADm9MDS2sYgSCXBLu0o80AHmQv58VY+qsH19pB9fc4Z8UhbQhgYtzR43pHjlVxzDiGaciAxcpf8/prJ0jNW0dKKa/bnZqOV7yqiw92eK1QTMyedKLlzX6mn2Q0pC13Vg42mZ9qp0sfnl+bK0FdbyzMOGwlIXDJb0xnqFunaGBm28+chJ4vDD2vM2APMNXTH5pCzpGNAPEI5tZrsqACyD6dLz1qRuIY4Rakg7nZMmYMvwg1HZ5JfZzcUT2uqIX6s8U0A6NeWPkYnferkqPJNGJWrf6/4PbKLyJlqRwuBhEhngDpd62VVnmq47pom/EkrrGG7etgFAM66z+ncBXjE3/lietzL2i5jEvke9QvTq2TdtBFU4X4iZIPpaqQn6H+7RIxt42sHRPLLJX9JGUac= 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 Tue, Sep 05, 2023 at 02:22:13PM -0700, Christoph Paasch wrote: > On Sep 4, 2023, at 2:22 PM, Catalin Marinas wrote: > > 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): > > I tried out your patch. It does resolve the false positive ! > > However, I am occasionally getting a report of a single object being > leaked. When I try to visualize it with `cat > /sys/kernel/debug/kmemleak`, the object does not show up anymore… How often do you trigger the scanning? Since kmemleak does not stop the world (as some garbage collectors do), there's potential for false positives (e.g. a reference to it is in a register on some CPU while being moved from one list to another). The heuristics employed for this is to checksum the object and only report if the checksum has not changed in successive scans. But this is still problematic if scanning is done quickly in succession. The default 10min scanning (even 1min) shouldn't be an issue. I had a plan to do a "stop_scan" option (using stop_machine) but never got the time to do this. > If you have an updated patch, let me know. I can test it. I sent it in reply to Joel. Thanks. -- Catalin