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 60797C48BDF for ; Tue, 15 Jun 2021 10:15:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4438961444 for ; Tue, 15 Jun 2021 10:15:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231431AbhFOKRZ (ORCPT ); Tue, 15 Jun 2021 06:17:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:36224 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231289AbhFOKRX (ORCPT ); Tue, 15 Jun 2021 06:17:23 -0400 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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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