From patchwork Tue Jun 7 16:30:25 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Will Deacon X-Patchwork-Id: 69553 Delivered-To: patch@linaro.org Received: by 10.140.106.246 with SMTP id e109csp2067401qgf; Tue, 7 Jun 2016 09:31:32 -0700 (PDT) X-Received: by 10.36.103.19 with SMTP id u19mr5248776itc.8.1465317090946; Tue, 07 Jun 2016 09:31:30 -0700 (PDT) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id b6si1108646pay.99.2016.06.07.09.31.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jun 2016 09:31:30 -0700 (PDT) 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 1bAJtf-0001cw-8L; Tue, 07 Jun 2016 16:30:31 +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 1bAJtb-0000Om-Sp for linux-arm-kernel@lists.infradead.org; Tue, 07 Jun 2016 16:30:28 +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 2F36F93D; Tue, 7 Jun 2016 09:30:42 -0700 (PDT) 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 BE5CD3F21A; Tue, 7 Jun 2016 09:30:06 -0700 (PDT) Date: Tue, 7 Jun 2016 17:30:25 +0100 From: Will Deacon To: Alexander Graf Subject: Re: [PATCH] arm64: Implement ptep_set_access_flags() for hardware AF/DBM Message-ID: <20160607163024.GB20477@arm.com> References: <1460559682-31267-1-git-send-email-catalin.marinas@arm.com> <4c2b3cff-d4a7-f3b8-ef0d-f6caa21f412e@suse.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4c2b3cff-d4a7-f3b8-ef0d-f6caa21f412e@suse.de> 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-20160607_093027_947332_88CFDB1C X-CRM114-Status: GOOD ( 19.14 ) X-Spam-Score: -8.3 (--------) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-8.3 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 -1.4 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: Catalin Marinas , Julien Grall , linux-arm-kernel@lists.infradead.org, Ming Lei Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org Hi Alex, Thanks for the bug report. On Tue, Jun 07, 2016 at 04:13:03PM +0200, Alexander Graf wrote: > On 13.04.16 17:01, Catalin Marinas wrote: > > When hardware updates of the access and dirty states are enabled, the > > default ptep_set_access_flags() implementation based on calling > > set_pte_at() directly is potentially racy. This triggers the "racy dirty > > state clearing" warning in set_pte_at() because an existing writable PTE > > is overridden with a clean entry. [...] > This patch breaks swapping for me. > > I've hit weird issues where systems stopped working half-way, with the > kernel still being fine and user space applications just stopping to > respond. > > After some debugging we found out that it always happens when swapping > (to anything, backing storage doesn't matter). A quick bisect points to > this commit as culprit and indeed, if I disable CONFIG_ARM64_HW_AFDBM > the system works as expected. [...] > The back traces indicate that the page fault handler goes through and > the process just keeps banging on the same page fault over and over > again. I have not yet figured out what *exactly* is going wrong or why > this patch would actually give us that effect. > > I was able to fully reproduce the issue with current Linus tree (4.7-rc2+). It looks like the following happens: 1. We put down a PTE_WRITE | PTE_DIRTY | PTE_AF pte 2. Memory pressure -> pte_mkold(pte) -> clear PTE_AF 3. A read faults due to the missing access flag 4. ptep_set_access_flags is called with dirty = 0, due to the read fault 5. pte is then made PTE_WRITE | PTE_DIRTY | PTE_AF | PTE_RDONLY (!) 6. A write faults, but pte_write is true so we get stuck Does the diff below fix the issue for you? If so, I'll write a proper patch. Cheers, Will --->8 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Reviewed-by: Catalin Marinas diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index 5954881a35ac..ba3fc12bd272 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -109,7 +109,7 @@ int ptep_set_access_flags(struct vm_area_struct *vma, * PTE_RDONLY is cleared by default in the asm below, so set it in * back if necessary (read-only or clean PTE). */ - if (!pte_write(entry) || !dirty) + if (!pte_write(entry) || !pte_sw_dirty(entry)) pte_val(entry) |= PTE_RDONLY; /*