Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2753390ybk; Tue, 12 May 2020 07:21:40 -0700 (PDT) X-Google-Smtp-Source: APiQypINtMgFYxc2v1G8WG7aXaOv7tuoR/sdF9FCYFfY7Rt3hURYUH3+5oWUBN2Ro+nm+Om6Dgh6 X-Received: by 2002:a17:906:4e8a:: with SMTP id v10mr17509395eju.63.1589293300732; Tue, 12 May 2020 07:21:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589293300; cv=none; d=google.com; s=arc-20160816; b=mpG/uxSiS9vIeVjAp+q8gORi3AFYQ0T2I/CIVOgyc/gAtgtGU86PhsQqwKuw/YKAbQ tyFgBmmLl6iAVRnAJjneRap2lm2ipiOgfCWAyvIAIaENLcoOaTjP6tA7arcNBLQLgDok 4VzHXqBiSHpJTVwp9Xmu1HgD4NA5RyXHJ9D+nBJ+aic2dw+PYeBiQm7ImjjKAyl+uZ4F n4XWfF+N761rLRDkI8gTFS1giff9ym7qsjwna7ggD8rCKkPcCnvVokcLiQnHLt9CDHK0 XGgpkGmJh/D7XjJhohxfDFHXA4hN7aOUZixlLjKDXuwON5UBj+fyssig2Mfq7rTh+xX4 0EwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=tzAKfRkm3+qPgKmppWJAqRX8qx2BALepNw3FugObEbY=; b=Lbag/ZC+NvlN+E4vp+wLe+GPYGcxgTn1/Ynz3eqhjnyI6fgyrBbhY4QX6/wI5YcQXB Iz3PldjlSLUu17mcraWCTqtI8N8q6BQlniJhAoVaYcM+7vfS1PVkX60QMIi/1JbdFdhT F/S1Mi1WZNnGNvlZXU0v1urwfL/aCBPfIA9Iy0QajRN/fhobzITGydP3RyWxKOBywHjl +0XmgZYj42Umzlf4PsV3VENg5RdUWXxEcyyUrlFjMQnhUpRDMJxsCAngFcA8qT6z2EQx F7fXtstv7yXz05vrK+Qt08/WwrjaJOLrgn9IGTsl4utp/PNjsomW4FeM7eBTAh9yJxPq 3lRg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g21si6855624edr.194.2020.05.12.07.21.17; Tue, 12 May 2020 07:21:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730339AbgELORc (ORCPT + 99 others); Tue, 12 May 2020 10:17:32 -0400 Received: from foss.arm.com ([217.140.110.172]:55932 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729336AbgELORb (ORCPT ); Tue, 12 May 2020 10:17:31 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 30DF230E; Tue, 12 May 2020 07:17:31 -0700 (PDT) Received: from gaia (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 032BB3F71E; Tue, 12 May 2020 07:17:29 -0700 (PDT) Date: Tue, 12 May 2020 15:17:23 +0100 From: Catalin Marinas To: Qian Cai Cc: Michael Ellerman , paulus@ozlabs.org, benh@kernel.crashing.org, kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] powerpc/kvm: silence kmemleak false positives Message-ID: <20200512141723.GB14943@gaia> References: <87y2pybu38.fsf@mpe.ellerman.id.au> <44807D44-98D9-431C-9266-08014C4B47F6@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <44807D44-98D9-431C-9266-08014C4B47F6@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 11, 2020 at 07:43:30AM -0400, Qian Cai wrote: > On May 11, 2020, at 7:15 AM, Michael Ellerman wrote: > > There is kmemleak_alloc_phys(), which according to the docs can be used > > for tracking a phys address. > > > > Did you try that? > > Catalin, feel free to give your thoughts here. > > My understanding is that it seems the doc is a bit misleading. > kmemleak_alloc_phys() is to allocate kmemleak objects for a physical > address range, so kmemleak could scan those memory pointers within > for possible referencing other memory. It was only used in memblock so > far, but those new memory allocations here contain no reference to > other memory. > > In this case, we have already had kmemleak objects for those memory > allocation. It is just that other pointers reference those memory by > their physical address which is a known kmemleak limitation won’t be > able to track the the connection. Thus, we always use > kmemleak_ignore() to not reporting those as leaks and don’t scan those > because they do not contain other memory reference. Indeed. I replied directly to Michael along the same lines. -- Catalin