From patchwork Wed Mar 9 15:31:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Will Deacon X-Patchwork-Id: 63718 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp2712276lbc; Wed, 9 Mar 2016 07:33:05 -0800 (PST) X-Received: by 10.98.73.88 with SMTP id w85mr35862197pfa.82.1457537585171; Wed, 09 Mar 2016 07:33:05 -0800 (PST) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id s80si13190600pfi.55.2016.03.09.07.33.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Mar 2016 07:33:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org 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 1adg5S-0007UJ-TB; Wed, 09 Mar 2016 15:31:46 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1adg5N-00070U-1J for linux-arm-kernel@lists.infradead.org; Wed, 09 Mar 2016 15:31:44 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8E3C749; Wed, 9 Mar 2016 07:30:18 -0800 (PST) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 53FC23F211; Wed, 9 Mar 2016 07:31:16 -0800 (PST) Date: Wed, 9 Mar 2016 15:31:32 +0000 From: Will Deacon To: Steve Capper Subject: Re: BUG in HugeTLBFS with Contiguous hint Message-ID: <20160309153131.GF28496@arm.com> References: <20160309021252.GA4573@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160309021252.GA4573@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160309_073141_100294_EE5A8C43 X-CRM114-Status: GOOD ( 22.30 ) X-Spam-Score: -6.9 (------) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-6.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [217.140.101.70 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dwoods@ezchip.com, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org On Wed, Mar 09, 2016 at 02:12:56AM +0000, Steve Capper wrote: > Hi, Hi Steve, > I am very sorry for the very late bug report. I have just come across > this error. > > Whilst testing something else, I found that 2MB HugeTLB pages formed > from contiguous pte's cause BUGs to appear when running through the > libhugetlbfs test suite. Ouch. Any idea why this wasn't spotted earlier? Did something else change? > I have been digging into this and I think the problem is due to the > huge pages not being unmapped properly (the nature of the bugs is that > compound pages have a non-negative compound mapped count, thus appear > as mapped in the hugetlbfs inode destruction logic); but I have not > yet been able to convincingly isolate the problem. > > I ran with 64KB PAGE_SIZE and CONFIG_DEBUG_VM. Failure mode at the > bottom of this email for a 4.5-rc7 kernel. > > Also, whilst reading through the code again, I think that > find_num_contig can be better implemented by pulling through the vma > (thus hstate) and avoid the need for a page table walk. This may make > things slightly more reliable when DBM is enabled (as the current code > depends on being able to pull out a matching pte), but would require > some core changes. > > I'll keep hacking, but, It may be better to temporarily disable (or > revert) contiguous hint hugetlb pages for now as I don't think a quick > fix can be found in time for the release. A revert is certainly the easiest option, but it also seems unfortunate. Maybe something like the patch below instead? It can be reverted as soon as this is worked out. Can you confirm that this avoids the BUG? Will --->8 >From ff7925848b50050732ac0401e0acf27e8b241d7b Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Wed, 9 Mar 2016 15:22:55 +0000 Subject: [PATCH] arm64: hugetlb: partial revert of 66b3923a1a0f Commit 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit") introduced support for huge pages using the contiguous bit in the PTE as opposed to block mappings, which may be slightly unwieldy (512M) in 64k page configurations. Unfortunately, this support has resulted in some late regressions when running the libhugetlbfs test suite with 64k pages and CONFIG_DEBUG_VM as a result of a BUG: | readback (2M: 64): ------------[ cut here ]------------ | kernel BUG at fs/hugetlbfs/inode.c:446! | Internal error: Oops - BUG: 0 [#1] SMP | Modules linked in: | CPU: 7 PID: 1448 Comm: readback Not tainted 4.5.0-rc7 #148 | Hardware name: linux,dummy-virt (DT) | task: fffffe0040964b00 ti: fffffe00c2668000 task.ti: fffffe00c2668000 | PC is at remove_inode_hugepages+0x44c/0x480 | LR is at remove_inode_hugepages+0x264/0x480 Rather than revert the entire patch, simply avoid advertising the contiguous huge page sizes for now while people are actively working on a fix. This patch can then be reverted once things have been sorted out. Cc: David Woods Reported-by: Steve Capper Signed-off-by: Will Deacon --- arch/arm64/mm/hugetlbpage.c | 14 -------------- 1 file changed, 14 deletions(-) -- 2.1.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c index 82d607c3614e..da30529bb1f6 100644 --- a/arch/arm64/mm/hugetlbpage.c +++ b/arch/arm64/mm/hugetlbpage.c @@ -306,10 +306,6 @@ static __init int setup_hugepagesz(char *opt) hugetlb_add_hstate(PMD_SHIFT - PAGE_SHIFT); } else if (ps == PUD_SIZE) { hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT); - } else if (ps == (PAGE_SIZE * CONT_PTES)) { - hugetlb_add_hstate(CONT_PTE_SHIFT); - } else if (ps == (PMD_SIZE * CONT_PMDS)) { - hugetlb_add_hstate((PMD_SHIFT + CONT_PMD_SHIFT) - PAGE_SHIFT); } else { pr_err("hugepagesz: Unsupported page size %lu K\n", ps >> 10); return 0; @@ -317,13 +313,3 @@ static __init int setup_hugepagesz(char *opt) return 1; } __setup("hugepagesz=", setup_hugepagesz); - -#ifdef CONFIG_ARM64_64K_PAGES -static __init int add_default_hugepagesz(void) -{ - if (size_to_hstate(CONT_PTES * PAGE_SIZE) == NULL) - hugetlb_add_hstate(CONT_PMD_SHIFT); - return 0; -} -arch_initcall(add_default_hugepagesz); -#endif