From patchwork Fri Jul 25 19:00:37 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Salter X-Patchwork-Id: 34313 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-wi0-f197.google.com (mail-wi0-f197.google.com [209.85.212.197]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id E47AC20551 for ; Fri, 25 Jul 2014 19:02:38 +0000 (UTC) Received: by mail-wi0-f197.google.com with SMTP id bs8sf933242wib.8 for ; Fri, 25 Jul 2014 12:02:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:message-id:subject:from:to:date :organization:mime-version:cc:precedence:list-id:list-unsubscribe :list-archive:list-post:list-help:list-subscribe:sender:errors-to :x-original-sender:x-original-authentication-results:mailing-list :content-type:content-transfer-encoding; bh=b/HSa/VLeN0owIH2h3256Uu1/3Sc7iCuhizYS4yfF7Y=; b=ERp+H2oxXkNJ8RWdzqTwm1rRvNuuBrlo/6TRVWWWCvCEEuU2yRojqZugWIOZn697QH gSIHdAvijtYwt8r+Ybi+zeKTeBg9MqeRaTU0oSNXnkJ71zhJ5pyqPmHro14pr802lWng GHKwGsjHXK2mprfGBuSUUgTWVoqPuWDSfcuXlPIFxynUpdoktpqW0tB2z5tbaMzyVH+4 RwSsH2BQvVvBMbjRZkfukFp+cw/3+BS/1O8CFFiq7Lhf6oz3ausgRMpp2JZU7q/5vAyY ywJ/wa6h20SfVmoHHSflsjrJGA4WhXXIzk1enSHjsb64LBT0FhmO/Ey3S4PJG4d+DJ6u dq9A== X-Gm-Message-State: ALoCoQm6hzZ9ioz2tt6IhrwKG9OmeCwjPO/4VVoe8BHaXXctrQeqh3yPDlGueXTGCD0Tuk2D3ZUP X-Received: by 10.180.13.18 with SMTP id d18mr657683wic.2.1406314957889; Fri, 25 Jul 2014 12:02:37 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.24.74 with SMTP id 68ls1260996qgq.98.gmail; Fri, 25 Jul 2014 12:02:37 -0700 (PDT) X-Received: by 10.52.166.10 with SMTP id zc10mr4112554vdb.61.1406314957733; Fri, 25 Jul 2014 12:02:37 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id xq7si8111455veb.103.2014.07.25.12.02.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 12:02:37 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.172 as permitted sender) client-ip=209.85.220.172; Received: by mail-vc0-f172.google.com with SMTP id im17so7914599vcb.31 for ; Fri, 25 Jul 2014 12:02:37 -0700 (PDT) X-Received: by 10.220.118.136 with SMTP id v8mr4958707vcq.50.1406314957648; Fri, 25 Jul 2014 12:02:37 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.221.37.5 with SMTP id tc5csp59178vcb; Fri, 25 Jul 2014 12:02:37 -0700 (PDT) X-Received: by 10.70.44.206 with SMTP id g14mr18257457pdm.85.1406314956860; Fri, 25 Jul 2014 12:02:36 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id pw8si10088881pac.113.2014.07.25.12.02.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jul 2014 12:02:36 -0700 (PDT) Received-SPF: none (google.com: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org does not designate permitted sender hosts) client-ip=2001:1868:205::9; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XAkjt-0003Ha-U9; Fri, 25 Jul 2014 19:01:09 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XAkjr-0003At-D5 for linux-arm-kernel@lists.infradead.org; Fri, 25 Jul 2014 19:01:08 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6PJ0c7M014231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Jul 2014 15:00:38 -0400 Received: from [10.3.113.127] (ovpn-113-127.phx2.redhat.com [10.3.113.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6PJ0bJ9004752; Fri, 25 Jul 2014 15:00:37 -0400 Message-ID: <1406314837.27055.25.camel@deneb.redhat.com> Subject: memory leak in arm kvm From: Mark Salter To: christoffer.dall@linaro.org, marc.zyngier@arm.com Date: Fri, 25 Jul 2014 15:00:37 -0400 Organization: Red Hat, Inc Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140725_120107_490186_AE18FFF5 X-CRM114-Status: GOOD ( 14.31 ) X-Spam-Score: -5.0 (-----) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-5.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [209.132.183.28 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.132.183.28 listed in wl.mailspike.net] -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders Cc: kvmarm@lists.cs.columbia.edu, linux-arm-kernel X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: , List-Help: , List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: msalter@redhat.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.172 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 I've been looking into a memory leak in the arm kvm code which has been seen on arm64 platforms. It seems there is a small (2-4MB depending on pagesize) leak when a guest is started and stopped. The leak is happening in arch/arm/kvm/mmu.c when kvm_free_stage2_pgd() tries to unmap everything and free the pgd allocation. The problem I see is that unmap_range() does not remove all the page references to the pgd so when free_pages() is called, the pages are not actually freed because of page->count > 1. Looking further, the call to unmap_range() only ever calls put_page() once for the pgd and then it bails out of the while loop. This happens because of the arm64 kvm_p?d_addr_end() macros. They are defined to the normal p?d_addr_end macros. On arm64 with 3-level page tables, pud_addr_end() simply advances to the end. With 2-level page tables, pud_addr_end() and pmd_addr_end() both advance to end. So when the bottom of the while loop in unmap_range() uses those to advance to next pmd or pud, the loop ends up exiting. I can get around this by open coding the kvm_p?d_addr_end macros thusly: I'm not at all sure this is a correct/complete fix and I'm not really familiar with the design of the arm kvm code, so I'll leave it to others to decide that. diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h index 7d29847..d7f77ff 100644 --- a/arch/arm64/include/asm/kvm_mmu.h +++ b/arch/arm64/include/asm/kvm_mmu.h @@ -122,8 +122,16 @@ static inline void kvm_set_s2pmd_writable(pmd_t *pmd) } #define kvm_pgd_addr_end(addr, end) pgd_addr_end(addr, end) -#define kvm_pud_addr_end(addr, end) pud_addr_end(addr, end) -#define kvm_pmd_addr_end(addr, end) pmd_addr_end(addr, end) + +#define kvm_pud_addr_end(addr, end) \ +({ unsigned long __boundary = ((addr) + PUD_SIZE) & PUD_MASK; \ + (__boundary - 1 < (end) - 1)? __boundary: (end); \ +}) + +#define kvm_pmd_addr_end(addr, end) \ +({ unsigned long __boundary = ((addr) + PMD_SIZE) & PMD_MASK; \ + (__boundary - 1 < (end) - 1)? __boundary: (end); \ +}) struct kvm;