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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62F23C48BE8 for ; Tue, 15 Jun 2021 10:15:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0489561438 for ; Tue, 15 Jun 2021 10:15:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0489561438 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8C50E6B0070; Tue, 15 Jun 2021 06:15:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 874E86B0071; Tue, 15 Jun 2021 06:15:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7157D6B0072; Tue, 15 Jun 2021 06:15:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 3F0066B0070 for ; Tue, 15 Jun 2021 06:15:21 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C74FF180AD807 for ; Tue, 15 Jun 2021 10:15:20 +0000 (UTC) X-FDA: 78255550800.22.27234DF Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf19.hostedemail.com (Postfix) with ESMTP id 3CB369001E72 for ; Tue, 15 Jun 2021 10:15:09 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 51BB861443; Tue, 15 Jun 2021 10:15:18 +0000 (UTC) Date: Tue, 15 Jun 2021 11:15:15 +0100 From: Catalin Marinas To: Rustam Kovhaev Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, dvyukov@google.com, gregkh@linuxfoundation.org Subject: Re: kmemleak memory scanning Message-ID: <20210615101515.GC26027@arm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of cmarinas@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3CB369001E72 X-Stat-Signature: uj5unp83abotanqnekxdmsn8thgatt6x X-HE-Tag: 1623752109-633854 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 Rustam, On Mon, Jun 14, 2021 at 01:31:14PM -0700, Rustam Kovhaev wrote: > a) kmemleak scans struct page (kmemleak.c:1462), but it does not scan > the actual contents (page_address(page)) of the page. > if we allocate an object with kmalloc(), then allocate page with > alloc_page(), and if we put kmalloc pointer somewhere inside that page, > kmemleak will report kmalloc pointer as a false positive. > should we improve kmemleak and make it scan page contents? > or will this bring too many false negatives? This is indeed on purpose otherwise (1) we'd get a lot of false negatives and (2) the scanning would take significantly longer. There are a lot more pages allocated for user processes than used in the kernel, we don't need to scan them all. We do have a few places where we explicitly call kmemleak_alloc(): neigh_hash_alloc(), alloc_page_ext(), blk_mq_alloc_rqs(), early_amd_iommu_init(). > b) when kmemleak object gets created (kmemleak.c:598) it gets checksum > of 0, by the time user requests kmemleak "scan" via debugfs the pointer > will be most likely changed to some value by the kernel and during > first scan kmemleak won't report the object as orphan even if it did not > find any reference to it, because it will execute update_checksum() and > after that will proceed to updating object->count (kmemleak.c:1502). > and so the user will have to initiate a second "scan" via debugfs and > only then kmemleak will produce the report. > should we document this? That's a mitigation against false positives. Lot's of objects that get allocated just prior to a memory scan have a tendency to be reported as leaks before they get referenced via e.g. a list (and the in-object list_head structure updated). So you'd need to get the checksum identical in two consecutive scans to report it as a leak. We should probably document this. -- Catalin