Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1793423ybk; Mon, 11 May 2020 04:31:52 -0700 (PDT) X-Google-Smtp-Source: APiQypI3DSGHhMg43sgZ6/tZnG19aXZexN+AJA10fiTiNFp9lgwcY8lcEdEeslr1bDt/xMloV13A X-Received: by 2002:a05:6402:2035:: with SMTP id ay21mr5707321edb.279.1589196712085; Mon, 11 May 2020 04:31:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589196712; cv=none; d=google.com; s=arc-20160816; b=j927u8pcC20zqGLVOqZ2jBM8tlesgmlQLN2ntM/1xjAFZjkCGINWEvZovzC85Lyyng zYOW21P2K1egHr5bM+Jj7Y4P9dpJiL2PYpV8JwNZBcJ7Tk9NNvaFBU96+yw/htsD/DI2 Sr2Yp1XDQNZTh/CoQJvJSCpOZB6YC75iChNtEnmLqcw2P8tGpCw1t+yUvq5k3tgtBY9Y vFEgmz7O8i17J+KvBPGWjHtZ9OOE2KlLGFE98F8uMKHLzajJFcJMW6O6pO3F0ADuSU7s ioLhDdMgAfW0itCKfwokRHaqOJqjpQ863YP6LfJ5CSe+4g/NAAk7jLy2x4RRgwg6T+c0 qA6g== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=lnZinsBUPPuDkPeWeUyKg4Ozp/hmDjbTPFsW5ZK0v5M=; b=rKA5oUZ40IUN5Gh6UOGrP3Ccm5cEJMxe7qqS12xq6b8eclEKyMwiw2ySSQSn5NJYtD Z+Gt3nn4GjNU5Yh+Xfvp40DNMl+UzVDz8DfOY9c+sCC5FpWm9uSYK+i0Z2zgtguKbklK wMWItisoJ4ZUEwPEk2K+H9BzT+p0EcAz6xyNIkQaw8JoCTxcoQAvt3zfnzwQqgSYAcV3 b0XGID8vDf2wjmQgFEPD6f/D46XuApieNcmFeGzKSNnix1wJEqMkOmz3TcYppGOUDolm QC5ETwom/bxy0ONxqVmt+HdA5KbgV4vUPQu8oVTwhl8t9KGDq2XBBhREa57M0Bg2SlIt LMqA== 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 c21si2944025ejr.277.2020.05.11.04.31.28; Mon, 11 May 2020 04:31:52 -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 S1730050AbgEKL2k (ORCPT + 99 others); Mon, 11 May 2020 07:28:40 -0400 Received: from foss.arm.com ([217.140.110.172]:58216 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729333AbgEKL2i (ORCPT ); Mon, 11 May 2020 07:28:38 -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 A0B5D1FB; Mon, 11 May 2020 04:28:37 -0700 (PDT) Received: from gaia (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 75B2A3F305; Mon, 11 May 2020 04:28:36 -0700 (PDT) Date: Mon, 11 May 2020 12:28:30 +0100 From: Catalin Marinas To: Michael Ellerman Cc: Qian Cai , 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: <20200511112829.GB19176@gaia> References: <20200509015538.3183-1-cai@lca.pw> <87y2pybu38.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y2pybu38.fsf@mpe.ellerman.id.au> 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 09:15:55PM +1000, Michael Ellerman wrote: > Qian Cai writes: > > kvmppc_pmd_alloc() and kvmppc_pte_alloc() allocate some memory but then > > pud_populate() and pmd_populate() will use __pa() to reference the newly > > allocated memory. The same is in xive_native_provision_pages(). > > > > Since kmemleak is unable to track the physical memory resulting in false > > positives, silence those by using kmemleak_ignore(). > > There is kmemleak_alloc_phys(), which according to the docs can be used > for tracking a phys address. This won't help. While kmemleak_alloc_phys() allows passing a physical address, it doesn't track physical address references to this object. It still expects VA pointing to it, otherwise the object would be reported as a leak. We currently only call this from the memblock code with a min_count of 0, meaning it will not be reported as a leak if no references are found. We don't have this issue with page tables on other architectures since most of them use whole page allocations which aren't tracked by kmemleak. These powerpc functions use kmem_cache_alloc() which would be tracked automatically by kmemleak. While we could add a phys alias to kmemleak (another search tree), I think the easiest is as per Qian's patch, just ignore those objects. -- Catalin