From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux admin Subject: Re: [PATCH 3/5] mm/mremap: use pmd_addr_end to calculate next in move_page_tables() Date: Wed, 29 Jan 2020 09:47:38 +0000 Message-ID: <20200129094738.GE25745@shell.armlinux.org.uk> References: <20200117232254.2792-1-richardw.yang@linux.intel.com> <20200117232254.2792-4-richardw.yang@linux.intel.com> <7147774a-14e9-4ff3-1548-4565f0d214d5@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: <7147774a-14e9-4ff3-1548-4565f0d214d5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Dmitry Osipenko Cc: Wei Yang , akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, aneesh.kumar-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org, kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org, yang.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org, thellstrom-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org, Thierry Reding , Jon Hunter , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: linux-tegra@vger.kernel.org On Sun, Jan 26, 2020 at 05:47:57PM +0300, Dmitry Osipenko wrote: > 18.01.2020 02:22, Wei Yang пишет: > > Use the general helper instead of do it by hand. > > > > Signed-off-by: Wei Yang > > --- > > mm/mremap.c | 7 ++----- > > 1 file changed, 2 insertions(+), 5 deletions(-) > > > > diff --git a/mm/mremap.c b/mm/mremap.c > > index c2af8ba4ba43..a258914f3ee1 100644 > > --- a/mm/mremap.c > > +++ b/mm/mremap.c > > @@ -253,11 +253,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > > > > for (; old_addr < old_end; old_addr += extent, new_addr += extent) { > > cond_resched(); > > - next = (old_addr + PMD_SIZE) & PMD_MASK; > > - /* even if next overflowed, extent below will be ok */ > > + next = pmd_addr_end(old_addr, old_end); > > extent = next - old_addr; > > - if (extent > old_end - old_addr) > > - extent = old_end - old_addr; > > old_pmd = get_old_pmd(vma->vm_mm, old_addr); > > if (!old_pmd) > > continue; > > @@ -301,7 +298,7 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > > > > if (pte_alloc(new_vma->vm_mm, new_pmd)) > > break; > > - next = (new_addr + PMD_SIZE) & PMD_MASK; > > + next = pmd_addr_end(new_addr, new_addr + len); > > if (extent > next - new_addr) > > extent = next - new_addr; > > move_ptes(vma, old_pmd, old_addr, old_addr + extent, new_vma, > > > > Hello Wei, > > Starting with next-20200122, I'm seeing the following in KMSG on NVIDIA > Tegra (ARM32): > > BUG: Bad rss-counter state mm:(ptrval) type:MM_ANONPAGES val:190 > > and eventually kernel hangs. > > Git's bisection points to this patch and reverting it helps. Please fix, > thanks in advance. The above is definitely wrong - pXX_addr_end() are designed to be used with an address index within the pXX table table and the address index of either the last entry in the same pXX table or the beginning of the _next_ pXX table. Arbitary end address indicies are not allowed. When page tables are "rolled up" when levels don't exist, it is common practice for these macros to just return their end address index. Hence, if they are used with arbitary end address indicies, then the iteration will fail. The only way to do this is: next = pmd_addr_end(old_addr, pud_addr_end(old_addr, p4d_addr_end(old_addr, pgd_addr_end(old_addr, old_end)))); which gives pmd_addr_end() (and each of the intermediate pXX_addr_end()) the correct end argument. However, that's a more complex and verbose, and likely less efficient than the current code. I'd suggest that there's nothing to "fix" in the v5.5 code wrt this, and trying to "clean it up" will just result in less efficient or broken code. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_DBL_ABUSE_MALW,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D30DFC33CB2 for ; Wed, 29 Jan 2020 09:48:43 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8EDD32070E for ; Wed, 29 Jan 2020 09:48:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="d/elPFDo"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="yfEDN2R2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8EDD32070E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=QWHuxQ6eDz7PRFXFBpQurP336CMFRgCs62+BfShNCFw=; b=d/elPFDovLcUP6 AW5V0SCVSd0Vw9DRu/rhQweb9DFtrFXa/l99vd59vGgAGtfqR8+zX5O8pJ79JzYlGKzy7oLCHXh9A g6M1HA2XKKBejB3kX3dGsBAlP9yzeEowr2GKqYaqqSnKPm1nOkB54qzJS91WuDUw6XLjdMeWIbZ/j /eKKnlG9A4mCkgjseTM/7BXmmtR6XMUJrotWDG2JXum/t/qe4+HWxmKA0g/QmZgMdj1np3Sriq079 67u4HlyhOy5amep6mDfNBzDfkQiyBGtjF8S3xjJeQAB3iRqrmSgO9ZhkgIJrcbdFD/D/DYPy2boMN tMJj+aroYOe0+mnhNC4A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iwjxb-0006Fb-4w; Wed, 29 Jan 2020 09:48:35 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iwjxU-0006E6-K5 for linux-arm-kernel@lists.infradead.org; Wed, 29 Jan 2020 09:48:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tdgu2B6VkKjHr97Y8fC+KukdGL6S2alhGVcqAPRvCZ8=; b=yfEDN2R2+5z1iS5UobX7oGhu6 uQKOGb5MnqvVJgW7JMSmK6eQAw4mz7g0Xudql/QY7FFhPD/YR8r5MTJeQdLIbHNfm1F03x2l/qEq+ VQFxR5CZ3SfJtiMdN4qC4Py6u7vn2ywU462tPtLL/Ew9DNP2BqCs6I8mhnWM8gPx9RKtfs/ki37kc AtuHlG0LYlQxtymcRYsiRW6LwtxEEdySYS92j9bavLUwEz9R9/2yNnc58PE81jlRH6Hppdqts7fnc 4qNos28VZmis7T/XlTTA6JuaPXYCADMUrhkB008zKP21S9VUwufI2LZU9jfkXTCJLnN+tlqFQ09r+ gNT1jw3qg==; Received: from shell.armlinux.org.uk ([2002:4e20:1eda:1:5054:ff:fe00:4ec]:40686) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1iwjwo-0004cD-0g; Wed, 29 Jan 2020 09:47:46 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1iwjwg-0003Id-Df; Wed, 29 Jan 2020 09:47:38 +0000 Date: Wed, 29 Jan 2020 09:47:38 +0000 From: Russell King - ARM Linux admin To: Dmitry Osipenko Subject: Re: [PATCH 3/5] mm/mremap: use pmd_addr_end to calculate next in move_page_tables() Message-ID: <20200129094738.GE25745@shell.armlinux.org.uk> References: <20200117232254.2792-1-richardw.yang@linux.intel.com> <20200117232254.2792-4-richardw.yang@linux.intel.com> <7147774a-14e9-4ff3-1548-4565f0d214d5@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7147774a-14e9-4ff3-1548-4565f0d214d5@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200129_014830_470245_1C804DC1 X-CRM114-Status: GOOD ( 18.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: thellstrom@vmware.com, yang.shi@linux.alibaba.com, aneesh.kumar@linux.ibm.com, linux-kernel@vger.kernel.org, Jon Hunter , linux-mm@kvack.org, Thierry Reding , Wei Yang , "linux-tegra@vger.kernel.org" , kirill@shutemov.name, akpm@linux-foundation.org, dan.j.williams@intel.com, "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gU3VuLCBKYW4gMjYsIDIwMjAgYXQgMDU6NDc6NTdQTSArMDMwMCwgRG1pdHJ5IE9zaXBlbmtv IHdyb3RlOgo+IDE4LjAxLjIwMjAgMDI6MjIsIFdlaSBZYW5nINC/0LjRiNC10YI6Cj4gPiBVc2Ug dGhlIGdlbmVyYWwgaGVscGVyIGluc3RlYWQgb2YgZG8gaXQgYnkgaGFuZC4KPiA+IAo+ID4gU2ln bmVkLW9mZi1ieTogV2VpIFlhbmcgPHJpY2hhcmR3LnlhbmdAbGludXguaW50ZWwuY29tPgo+ID4g LS0tCj4gPiAgbW0vbXJlbWFwLmMgfCA3ICsrLS0tLS0KPiA+ICAxIGZpbGUgY2hhbmdlZCwgMiBp bnNlcnRpb25zKCspLCA1IGRlbGV0aW9ucygtKQo+ID4gCj4gPiBkaWZmIC0tZ2l0IGEvbW0vbXJl bWFwLmMgYi9tbS9tcmVtYXAuYwo+ID4gaW5kZXggYzJhZjhiYTRiYTQzLi5hMjU4OTE0ZjNlZTEg MTAwNjQ0Cj4gPiAtLS0gYS9tbS9tcmVtYXAuYwo+ID4gKysrIGIvbW0vbXJlbWFwLmMKPiA+IEBA IC0yNTMsMTEgKzI1Myw4IEBAIHVuc2lnbmVkIGxvbmcgbW92ZV9wYWdlX3RhYmxlcyhzdHJ1Y3Qg dm1fYXJlYV9zdHJ1Y3QgKnZtYSwKPiA+ICAKPiA+ICAJZm9yICg7IG9sZF9hZGRyIDwgb2xkX2Vu ZDsgb2xkX2FkZHIgKz0gZXh0ZW50LCBuZXdfYWRkciArPSBleHRlbnQpIHsKPiA+ICAJCWNvbmRf cmVzY2hlZCgpOwo+ID4gLQkJbmV4dCA9IChvbGRfYWRkciArIFBNRF9TSVpFKSAmIFBNRF9NQVNL Owo+ID4gLQkJLyogZXZlbiBpZiBuZXh0IG92ZXJmbG93ZWQsIGV4dGVudCBiZWxvdyB3aWxsIGJl IG9rICovCj4gPiArCQluZXh0ID0gcG1kX2FkZHJfZW5kKG9sZF9hZGRyLCBvbGRfZW5kKTsKPiA+ ICAJCWV4dGVudCA9IG5leHQgLSBvbGRfYWRkcjsKPiA+IC0JCWlmIChleHRlbnQgPiBvbGRfZW5k IC0gb2xkX2FkZHIpCj4gPiAtCQkJZXh0ZW50ID0gb2xkX2VuZCAtIG9sZF9hZGRyOwo+ID4gIAkJ b2xkX3BtZCA9IGdldF9vbGRfcG1kKHZtYS0+dm1fbW0sIG9sZF9hZGRyKTsKPiA+ICAJCWlmICgh b2xkX3BtZCkKPiA+ICAJCQljb250aW51ZTsKPiA+IEBAIC0zMDEsNyArMjk4LDcgQEAgdW5zaWdu ZWQgbG9uZyBtb3ZlX3BhZ2VfdGFibGVzKHN0cnVjdCB2bV9hcmVhX3N0cnVjdCAqdm1hLAo+ID4g IAo+ID4gIAkJaWYgKHB0ZV9hbGxvYyhuZXdfdm1hLT52bV9tbSwgbmV3X3BtZCkpCj4gPiAgCQkJ YnJlYWs7Cj4gPiAtCQluZXh0ID0gKG5ld19hZGRyICsgUE1EX1NJWkUpICYgUE1EX01BU0s7Cj4g PiArCQluZXh0ID0gcG1kX2FkZHJfZW5kKG5ld19hZGRyLCBuZXdfYWRkciArIGxlbik7Cj4gPiAg CQlpZiAoZXh0ZW50ID4gbmV4dCAtIG5ld19hZGRyKQo+ID4gIAkJCWV4dGVudCA9IG5leHQgLSBu ZXdfYWRkcjsKPiA+ICAJCW1vdmVfcHRlcyh2bWEsIG9sZF9wbWQsIG9sZF9hZGRyLCBvbGRfYWRk ciArIGV4dGVudCwgbmV3X3ZtYSwKPiA+IAo+IAo+IEhlbGxvIFdlaSwKPiAKPiBTdGFydGluZyB3 aXRoIG5leHQtMjAyMDAxMjIsIEknbSBzZWVpbmcgdGhlIGZvbGxvd2luZyBpbiBLTVNHIG9uIE5W SURJQQo+IFRlZ3JhIChBUk0zMik6Cj4gCj4gICBCVUc6IEJhZCByc3MtY291bnRlciBzdGF0ZSBt bToocHRydmFsKSB0eXBlOk1NX0FOT05QQUdFUyB2YWw6MTkwCj4gCj4gYW5kIGV2ZW50dWFsbHkg a2VybmVsIGhhbmdzLgo+IAo+IEdpdCdzIGJpc2VjdGlvbiBwb2ludHMgdG8gdGhpcyBwYXRjaCBh bmQgcmV2ZXJ0aW5nIGl0IGhlbHBzLiBQbGVhc2UgZml4LAo+IHRoYW5rcyBpbiBhZHZhbmNlLgoK VGhlIGFib3ZlIGlzIGRlZmluaXRlbHkgd3JvbmcgLSBwWFhfYWRkcl9lbmQoKSBhcmUgZGVzaWdu ZWQgdG8gYmUgdXNlZAp3aXRoIGFuIGFkZHJlc3MgaW5kZXggd2l0aGluIHRoZSBwWFggdGFibGUg dGFibGUgYW5kIHRoZSBhZGRyZXNzIGluZGV4Cm9mIGVpdGhlciB0aGUgbGFzdCBlbnRyeSBpbiB0 aGUgc2FtZSBwWFggdGFibGUgb3IgdGhlIGJlZ2lubmluZyBvZiB0aGUKX25leHRfIHBYWCB0YWJs ZS4gIEFyYml0YXJ5IGVuZCBhZGRyZXNzIGluZGljaWVzIGFyZSBub3QgYWxsb3dlZC4KCldoZW4g cGFnZSB0YWJsZXMgYXJlICJyb2xsZWQgdXAiIHdoZW4gbGV2ZWxzIGRvbid0IGV4aXN0LCBpdCBp cyBjb21tb24KcHJhY3RpY2UgZm9yIHRoZXNlIG1hY3JvcyB0byBqdXN0IHJldHVybiB0aGVpciBl bmQgYWRkcmVzcyBpbmRleC4KSGVuY2UsIGlmIHRoZXkgYXJlIHVzZWQgd2l0aCBhcmJpdGFyeSBl bmQgYWRkcmVzcyBpbmRpY2llcywgdGhlbiB0aGUKaXRlcmF0aW9uIHdpbGwgZmFpbC4KClRoZSBv bmx5IHdheSB0byBkbyB0aGlzIGlzOgoKCW5leHQgPSBwbWRfYWRkcl9lbmQob2xkX2FkZHIsCgkJ CXB1ZF9hZGRyX2VuZChvbGRfYWRkciwKCQkJCXA0ZF9hZGRyX2VuZChvbGRfYWRkciwKCQkJCQlw Z2RfYWRkcl9lbmQob2xkX2FkZHIsIG9sZF9lbmQpKSkpOwoKd2hpY2ggZ2l2ZXMgcG1kX2FkZHJf ZW5kKCkgKGFuZCBlYWNoIG9mIHRoZSBpbnRlcm1lZGlhdGUgcFhYX2FkZHJfZW5kKCkpCnRoZSBj b3JyZWN0IGVuZCBhcmd1bWVudC4gIEhvd2V2ZXIsIHRoYXQncyBhIG1vcmUgY29tcGxleCBhbmQg dmVyYm9zZSwKYW5kIGxpa2VseSBsZXNzIGVmZmljaWVudCB0aGFuIHRoZSBjdXJyZW50IGNvZGUu CgpJJ2Qgc3VnZ2VzdCB0aGF0IHRoZXJlJ3Mgbm90aGluZyB0byAiZml4IiBpbiB0aGUgdjUuNSBj b2RlIHdydCB0aGlzLAphbmQgdHJ5aW5nIHRvICJjbGVhbiBpdCB1cCIgd2lsbCBqdXN0IHJlc3Vs dCBpbiBsZXNzIGVmZmljaWVudCBvcgpicm9rZW4gY29kZS4KCi0tIApSTUsncyBQYXRjaCBzeXN0 ZW06IGh0dHBzOi8vd3d3LmFybWxpbnV4Lm9yZy51ay9kZXZlbG9wZXIvcGF0Y2hlcy8KRlRUQyBi cm9hZGJhbmQgZm9yIDAuOG1pbGUgbGluZSBpbiBzdWJ1cmJpYTogc3luYyBhdCAxMi4xTWJwcyBk b3duIDYyMmticHMgdXAKQWNjb3JkaW5nIHRvIHNwZWVkdGVzdC5uZXQ6IDExLjlNYnBzIGRvd24g NTAwa2JwcyB1cAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5p bmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8v bGludXgtYXJtLWtlcm5lbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E46AAC33CB7 for ; Wed, 29 Jan 2020 09:48:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7EDBF2070E for ; Wed, 29 Jan 2020 09:48:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="yfEDN2R2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EDBF2070E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2DE6C6B0005; Wed, 29 Jan 2020 04:48:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 291EE6B0006; Wed, 29 Jan 2020 04:48:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CC846B0007; Wed, 29 Jan 2020 04:48:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0103.hostedemail.com [216.40.44.103]) by kanga.kvack.org (Postfix) with ESMTP id 06EFD6B0005 for ; Wed, 29 Jan 2020 04:48:20 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C00F72C96 for ; Wed, 29 Jan 2020 09:48:19 +0000 (UTC) X-FDA: 76430196318.24.crate39_2b760e08f4148 X-HE-Tag: crate39_2b760e08f4148 X-Filterd-Recvd-Size: 5735 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Wed, 29 Jan 2020 09:48:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tdgu2B6VkKjHr97Y8fC+KukdGL6S2alhGVcqAPRvCZ8=; b=yfEDN2R2+5z1iS5UobX7oGhu6 uQKOGb5MnqvVJgW7JMSmK6eQAw4mz7g0Xudql/QY7FFhPD/YR8r5MTJeQdLIbHNfm1F03x2l/qEq+ VQFxR5CZ3SfJtiMdN4qC4Py6u7vn2ywU462tPtLL/Ew9DNP2BqCs6I8mhnWM8gPx9RKtfs/ki37kc AtuHlG0LYlQxtymcRYsiRW6LwtxEEdySYS92j9bavLUwEz9R9/2yNnc58PE81jlRH6Hppdqts7fnc 4qNos28VZmis7T/XlTTA6JuaPXYCADMUrhkB008zKP21S9VUwufI2LZU9jfkXTCJLnN+tlqFQ09r+ gNT1jw3qg==; Received: from shell.armlinux.org.uk ([2002:4e20:1eda:1:5054:ff:fe00:4ec]:40686) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1iwjwo-0004cD-0g; Wed, 29 Jan 2020 09:47:46 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1iwjwg-0003Id-Df; Wed, 29 Jan 2020 09:47:38 +0000 Date: Wed, 29 Jan 2020 09:47:38 +0000 From: Russell King - ARM Linux admin To: Dmitry Osipenko Cc: Wei Yang , akpm@linux-foundation.org, dan.j.williams@intel.com, aneesh.kumar@linux.ibm.com, kirill@shutemov.name, yang.shi@linux.alibaba.com, thellstrom@vmware.com, Thierry Reding , Jon Hunter , linux-kernel@vger.kernel.org, linux-mm@kvack.org, "linux-tegra@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 3/5] mm/mremap: use pmd_addr_end to calculate next in move_page_tables() Message-ID: <20200129094738.GE25745@shell.armlinux.org.uk> References: <20200117232254.2792-1-richardw.yang@linux.intel.com> <20200117232254.2792-4-richardw.yang@linux.intel.com> <7147774a-14e9-4ff3-1548-4565f0d214d5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7147774a-14e9-4ff3-1548-4565f0d214d5@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Jan 26, 2020 at 05:47:57PM +0300, Dmitry Osipenko wrote: > 18.01.2020 02:22, Wei Yang =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > Use the general helper instead of do it by hand. > >=20 > > Signed-off-by: Wei Yang > > --- > > mm/mremap.c | 7 ++----- > > 1 file changed, 2 insertions(+), 5 deletions(-) > >=20 > > diff --git a/mm/mremap.c b/mm/mremap.c > > index c2af8ba4ba43..a258914f3ee1 100644 > > --- a/mm/mremap.c > > +++ b/mm/mremap.c > > @@ -253,11 +253,8 @@ unsigned long move_page_tables(struct vm_area_st= ruct *vma, > > =20 > > for (; old_addr < old_end; old_addr +=3D extent, new_addr +=3D exte= nt) { > > cond_resched(); > > - next =3D (old_addr + PMD_SIZE) & PMD_MASK; > > - /* even if next overflowed, extent below will be ok */ > > + next =3D pmd_addr_end(old_addr, old_end); > > extent =3D next - old_addr; > > - if (extent > old_end - old_addr) > > - extent =3D old_end - old_addr; > > old_pmd =3D get_old_pmd(vma->vm_mm, old_addr); > > if (!old_pmd) > > continue; > > @@ -301,7 +298,7 @@ unsigned long move_page_tables(struct vm_area_str= uct *vma, > > =20 > > if (pte_alloc(new_vma->vm_mm, new_pmd)) > > break; > > - next =3D (new_addr + PMD_SIZE) & PMD_MASK; > > + next =3D pmd_addr_end(new_addr, new_addr + len); > > if (extent > next - new_addr) > > extent =3D next - new_addr; > > move_ptes(vma, old_pmd, old_addr, old_addr + extent, new_vma, > >=20 >=20 > Hello Wei, >=20 > Starting with next-20200122, I'm seeing the following in KMSG on NVIDIA > Tegra (ARM32): >=20 > BUG: Bad rss-counter state mm:(ptrval) type:MM_ANONPAGES val:190 >=20 > and eventually kernel hangs. >=20 > Git's bisection points to this patch and reverting it helps. Please fix= , > thanks in advance. The above is definitely wrong - pXX_addr_end() are designed to be used with an address index within the pXX table table and the address index of either the last entry in the same pXX table or the beginning of the _next_ pXX table. Arbitary end address indicies are not allowed. When page tables are "rolled up" when levels don't exist, it is common practice for these macros to just return their end address index. Hence, if they are used with arbitary end address indicies, then the iteration will fail. The only way to do this is: next =3D pmd_addr_end(old_addr, pud_addr_end(old_addr, p4d_addr_end(old_addr, pgd_addr_end(old_addr, old_end)))); which gives pmd_addr_end() (and each of the intermediate pXX_addr_end()) the correct end argument. However, that's a more complex and verbose, and likely less efficient than the current code. I'd suggest that there's nothing to "fix" in the v5.5 code wrt this, and trying to "clean it up" will just result in less efficient or broken code. --=20 RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbp= s up According to speedtest.net: 11.9Mbps down 500kbps up