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: Thu, 30 Jan 2020 14:15:05 +0000 Message-ID: <20200130141505.GK25745@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> <20200129094738.GE25745@shell.armlinux.org.uk> <20200129215745.GA20736@richard> <20200129232441.GI25745@shell.armlinux.org.uk> <20200130013000.GA5137@richard> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: <20200130013000.GA5137@richard> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Wei Yang Cc: Dmitry Osipenko , 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 Thu, Jan 30, 2020 at 09:30:00AM +0800, Wei Yang wrote: > On Wed, Jan 29, 2020 at 11:24:41PM +0000, Russell King - ARM Linux admin wrote: > >On Thu, Jan 30, 2020 at 05:57:45AM +0800, Wei Yang wrote: > >> On Wed, Jan 29, 2020 at 09:47:38AM +0000, Russell King - ARM Linux admin wrote: > >> >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. > >> > > >> > >> #define pmd_addr_end(addr, end) \ > >> ({ unsigned long __boundary = ((addr) + PMD_SIZE) & PMD_MASK; \ > >> (__boundary - 1 < (end) - 1)? __boundary: (end); \ > >> }) > >> > >> If my understanding is correct, the definition here align the addr to next PMD > >> boundary or end. > >> > >> I don't see the possibility to across another PMD. Do I miss something? > > > >Look at the definition of p*_addr_end() that are used when page tables > >are rolled up. > > > > Sorry, I don't get your point. > > What's the meaning of "roll up" here? > > Would you mind giving me an example? I see pmd_addr_end() is not used in many > places in core kernel. By glancing those usages, all the places use it like > pmd_addr_end(addr, end). Seems no specially handing on the end address. > > Or you mean the case when pmd_addr_end() is defined to return "end" directly? Not all hardware has five levels of page tables. When hardware does not have five levels, it is common to "roll up" some of the page tables into others. There are generic ways to implement this, which include using: include/asm-generic/pgtable-nop4d.h include/asm-generic/pgtable-nopud.h include/asm-generic/pgtable-nopmd.h and then there's architecture ways to implement this. 32-bit ARM takes its implementation for PMD not from the generic version, which post-dates 32-bit ARM, but from how page table roll-up was implemented back at the time when the current ARM scheme was devised. The generic scheme is unsuitable for 32-bit ARM since we do more than just roll-up page tables, but this is irrelevent for this discussion. All three of the generic implementations, and 32-bit ARM, define the pXX_addr_end() macros thusly: include/asm-generic/pgtable-nop4d.h:#define p4d_addr_end(addr, end) (end) include/asm-generic/pgtable-nopmd.h:#define pmd_addr_end(addr, end) (end) include/asm-generic/pgtable-nopud.h:#define pud_addr_end(addr, end) (end) arch/arm/include/asm/pgtable-2level.h:#define pmd_addr_end(addr,end) (end) since, as I stated, pXX_addr_end() expects its "end" argument to be the address index of the next entry in the immediately upper page table level, or the address index of the last entry we wish to process, which ever is smaller. If it's larger than the address index of the next entry in the immediately upper page table level, then the effect of all these macros will be to walk off the end of the current level of page table. To see how they _should_ be used, see the loops in free_pgd_range() and the free_pXX_range() functions called from there and below. In all cases when the pXX_addr_end() macro was introduced, what I state above holds true - and I believe still holds true today, until this patch that has reportedly caused issues. -- 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 2E7B0C2D0DB for ; Thu, 30 Jan 2020 14:15:57 +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 01A1520CC7 for ; Thu, 30 Jan 2020 14:15:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CVCbFcZn"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="gZUm7KU4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 01A1520CC7 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=ecEIfwFZeelUAuUuB/STMKa9/0v1byW3ondgtJ4r5k4=; b=CVCbFcZnz7bQS9 AR2/14ytNyr7UoEjRIbOjQEoRSyHaDjNnERCnO/0fZXnWcpx7zBzzt19xmnkI/YUBGMtl8bHl7Njo 8TFGSSzTCg6sLWIbP/P0p+gujsZuQGRSshWQgyZ8TgD7xtAaeJvZeaDAUO0s07bT2Q2fWrQgjSYGC Odq/VdBG55GJbEO3+zMVn5pnjqHHxErK5ttkHOD0//dYkvDkM9acqEbnlnOYGuYM5MOQ2kIp4gk82 o4U2AcQUksPkgWVyv3K57aiKRYORgI0Z6T1UMYWEojCw0a7c9hZt39qMmFerzxtd1vFYlgcdbsaGF ZgLcEkFWXnjEfOGwRwUQ==; 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 1ixAbk-00053V-RX; Thu, 30 Jan 2020 14:15:48 +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 1ixAbg-00052D-3G for linux-arm-kernel@lists.infradead.org; Thu, 30 Jan 2020 14:15:46 +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=gX6hyt20QV23hW9BRxe2F20Xz12H4clKTdo4rjaVKBc=; b=gZUm7KU4jFD/ciDCawzCmQ4Qk BbhLC8I4sZQXvUmlzEilMB1DVfY3XM3xypcYqkiLSIJOeNRHBJLlXy1+SttaI9bOTE4tqilqEUTp3 zuwGWZDR4DrnNm2V16/SirM6jMaoTXTqQ/14Fk5HuHvbogzgsSGkEOaDFKhH57y9KJB2N8cd6rIwk 4iIlgmchckGeFZjvrlcJJawcO/0Fsb/5KD5oJUSFEUSGEmR8zSn0fU5HGTrvGr87HXpPkOSuywh0q 3doHTSTEUH+1o2SRqlk/y4CZyoPo+OTr17xSPuPx2WwmBGflMV3yQxpdmoFuSAPGdlTp8xI1dLMPV Yog7MvofQ==; Received: from shell.armlinux.org.uk ([2001:4d48:ad52:3201:5054:ff:fe00:4ec]:33698) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ixAb9-0003h7-6h; Thu, 30 Jan 2020 14:15:11 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1ixAb3-0004SG-Mt; Thu, 30 Jan 2020 14:15:05 +0000 Date: Thu, 30 Jan 2020 14:15:05 +0000 From: Russell King - ARM Linux admin To: Wei Yang Subject: Re: [PATCH 3/5] mm/mremap: use pmd_addr_end to calculate next in move_page_tables() Message-ID: <20200130141505.GK25745@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> <20200129094738.GE25745@shell.armlinux.org.uk> <20200129215745.GA20736@richard> <20200129232441.GI25745@shell.armlinux.org.uk> <20200130013000.GA5137@richard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200130013000.GA5137@richard> 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-20200130_061545_020886_39986E51 X-CRM114-Status: GOOD ( 28.18 ) 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, akpm@linux-foundation.org, aneesh.kumar@linux.ibm.com, linux-kernel@vger.kernel.org, Jon Hunter , linux-mm@kvack.org, Thierry Reding , "linux-tegra@vger.kernel.org" , kirill@shutemov.name, Dmitry Osipenko , 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 T24gVGh1LCBKYW4gMzAsIDIwMjAgYXQgMDk6MzA6MDBBTSArMDgwMCwgV2VpIFlhbmcgd3JvdGU6 Cj4gT24gV2VkLCBKYW4gMjksIDIwMjAgYXQgMTE6MjQ6NDFQTSArMDAwMCwgUnVzc2VsbCBLaW5n IC0gQVJNIExpbnV4IGFkbWluIHdyb3RlOgo+ID5PbiBUaHUsIEphbiAzMCwgMjAyMCBhdCAwNTo1 Nzo0NUFNICswODAwLCBXZWkgWWFuZyB3cm90ZToKPiA+PiBPbiBXZWQsIEphbiAyOSwgMjAyMCBh dCAwOTo0NzozOEFNICswMDAwLCBSdXNzZWxsIEtpbmcgLSBBUk0gTGludXggYWRtaW4gd3JvdGU6 Cj4gPj4gPk9uIFN1biwgSmFuIDI2LCAyMDIwIGF0IDA1OjQ3OjU3UE0gKzAzMDAsIERtaXRyeSBP c2lwZW5rbyB3cm90ZToKPiA+PiA+PiAxOC4wMS4yMDIwIDAyOjIyLCBXZWkgWWFuZyDQv9C40YjQ tdGCOgo+ID4+ID4+ID4gVXNlIHRoZSBnZW5lcmFsIGhlbHBlciBpbnN0ZWFkIG9mIGRvIGl0IGJ5 IGhhbmQuCj4gPj4gPj4gPiAKPiA+PiA+PiA+IFNpZ25lZC1vZmYtYnk6IFdlaSBZYW5nIDxyaWNo YXJkdy55YW5nQGxpbnV4LmludGVsLmNvbT4KPiA+PiA+PiA+IC0tLQo+ID4+ID4+ID4gIG1tL21y ZW1hcC5jIHwgNyArKy0tLS0tCj4gPj4gPj4gPiAgMSBmaWxlIGNoYW5nZWQsIDIgaW5zZXJ0aW9u cygrKSwgNSBkZWxldGlvbnMoLSkKPiA+PiA+PiA+IAo+ID4+ID4+ID4gZGlmZiAtLWdpdCBhL21t L21yZW1hcC5jIGIvbW0vbXJlbWFwLmMKPiA+PiA+PiA+IGluZGV4IGMyYWY4YmE0YmE0My4uYTI1 ODkxNGYzZWUxIDEwMDY0NAo+ID4+ID4+ID4gLS0tIGEvbW0vbXJlbWFwLmMKPiA+PiA+PiA+ICsr KyBiL21tL21yZW1hcC5jCj4gPj4gPj4gPiBAQCAtMjUzLDExICsyNTMsOCBAQCB1bnNpZ25lZCBs b25nIG1vdmVfcGFnZV90YWJsZXMoc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEsCj4gPj4gPj4g PiAgCj4gPj4gPj4gPiAgCWZvciAoOyBvbGRfYWRkciA8IG9sZF9lbmQ7IG9sZF9hZGRyICs9IGV4 dGVudCwgbmV3X2FkZHIgKz0gZXh0ZW50KSB7Cj4gPj4gPj4gPiAgCQljb25kX3Jlc2NoZWQoKTsK PiA+PiA+PiA+IC0JCW5leHQgPSAob2xkX2FkZHIgKyBQTURfU0laRSkgJiBQTURfTUFTSzsKPiA+ PiA+PiA+IC0JCS8qIGV2ZW4gaWYgbmV4dCBvdmVyZmxvd2VkLCBleHRlbnQgYmVsb3cgd2lsbCBi ZSBvayAqLwo+ID4+ID4+ID4gKwkJbmV4dCA9IHBtZF9hZGRyX2VuZChvbGRfYWRkciwgb2xkX2Vu ZCk7Cj4gPj4gPj4gPiAgCQlleHRlbnQgPSBuZXh0IC0gb2xkX2FkZHI7Cj4gPj4gPj4gPiAtCQlp ZiAoZXh0ZW50ID4gb2xkX2VuZCAtIG9sZF9hZGRyKQo+ID4+ID4+ID4gLQkJCWV4dGVudCA9IG9s ZF9lbmQgLSBvbGRfYWRkcjsKPiA+PiA+PiA+ICAJCW9sZF9wbWQgPSBnZXRfb2xkX3BtZCh2bWEt PnZtX21tLCBvbGRfYWRkcik7Cj4gPj4gPj4gPiAgCQlpZiAoIW9sZF9wbWQpCj4gPj4gPj4gPiAg CQkJY29udGludWU7Cj4gPj4gPj4gPiBAQCAtMzAxLDcgKzI5OCw3IEBAIHVuc2lnbmVkIGxvbmcg bW92ZV9wYWdlX3RhYmxlcyhzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKnZtYSwKPiA+PiA+PiA+ICAK PiA+PiA+PiA+ICAJCWlmIChwdGVfYWxsb2MobmV3X3ZtYS0+dm1fbW0sIG5ld19wbWQpKQo+ID4+ ID4+ID4gIAkJCWJyZWFrOwo+ID4+ID4+ID4gLQkJbmV4dCA9IChuZXdfYWRkciArIFBNRF9TSVpF KSAmIFBNRF9NQVNLOwo+ID4+ID4+ID4gKwkJbmV4dCA9IHBtZF9hZGRyX2VuZChuZXdfYWRkciwg bmV3X2FkZHIgKyBsZW4pOwo+ID4+ID4+ID4gIAkJaWYgKGV4dGVudCA+IG5leHQgLSBuZXdfYWRk cikKPiA+PiA+PiA+ICAJCQlleHRlbnQgPSBuZXh0IC0gbmV3X2FkZHI7Cj4gPj4gPj4gPiAgCQlt b3ZlX3B0ZXModm1hLCBvbGRfcG1kLCBvbGRfYWRkciwgb2xkX2FkZHIgKyBleHRlbnQsIG5ld192 bWEsCj4gPj4gPj4gPiAKPiA+PiA+PiAKPiA+PiA+PiBIZWxsbyBXZWksCj4gPj4gPj4gCj4gPj4g Pj4gU3RhcnRpbmcgd2l0aCBuZXh0LTIwMjAwMTIyLCBJJ20gc2VlaW5nIHRoZSBmb2xsb3dpbmcg aW4gS01TRyBvbiBOVklESUEKPiA+PiA+PiBUZWdyYSAoQVJNMzIpOgo+ID4+ID4+IAo+ID4+ID4+ ICAgQlVHOiBCYWQgcnNzLWNvdW50ZXIgc3RhdGUgbW06KHB0cnZhbCkgdHlwZTpNTV9BTk9OUEFH RVMgdmFsOjE5MAo+ID4+ID4+IAo+ID4+ID4+IGFuZCBldmVudHVhbGx5IGtlcm5lbCBoYW5ncy4K PiA+PiA+PiAKPiA+PiA+PiBHaXQncyBiaXNlY3Rpb24gcG9pbnRzIHRvIHRoaXMgcGF0Y2ggYW5k IHJldmVydGluZyBpdCBoZWxwcy4gUGxlYXNlIGZpeCwKPiA+PiA+PiB0aGFua3MgaW4gYWR2YW5j ZS4KPiA+PiA+Cj4gPj4gPlRoZSBhYm92ZSBpcyBkZWZpbml0ZWx5IHdyb25nIC0gcFhYX2FkZHJf ZW5kKCkgYXJlIGRlc2lnbmVkIHRvIGJlIHVzZWQKPiA+PiA+d2l0aCBhbiBhZGRyZXNzIGluZGV4 IHdpdGhpbiB0aGUgcFhYIHRhYmxlIHRhYmxlIGFuZCB0aGUgYWRkcmVzcyBpbmRleAo+ID4+ID5v ZiBlaXRoZXIgdGhlIGxhc3QgZW50cnkgaW4gdGhlIHNhbWUgcFhYIHRhYmxlIG9yIHRoZSBiZWdp bm5pbmcgb2YgdGhlCj4gPj4gPl9uZXh0XyBwWFggdGFibGUuICBBcmJpdGFyeSBlbmQgYWRkcmVz cyBpbmRpY2llcyBhcmUgbm90IGFsbG93ZWQuCj4gPj4gPgo+ID4+IAo+ID4+ICNkZWZpbmUgcG1k X2FkZHJfZW5kKGFkZHIsIGVuZCkJCQkJCQlcCj4gPj4gKHsJdW5zaWduZWQgbG9uZyBfX2JvdW5k YXJ5ID0gKChhZGRyKSArIFBNRF9TSVpFKSAmIFBNRF9NQVNLOwlcCj4gPj4gCShfX2JvdW5kYXJ5 IC0gMSA8IChlbmQpIC0gMSk/IF9fYm91bmRhcnk6IChlbmQpOwkJXAo+ID4+IH0pCj4gPj4gCj4g Pj4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB0aGUgZGVmaW5pdGlvbiBoZXJlIGFs aWduIHRoZSBhZGRyIHRvIG5leHQgUE1ECj4gPj4gYm91bmRhcnkgb3IgZW5kLgo+ID4+IAo+ID4+ IEkgZG9uJ3Qgc2VlIHRoZSBwb3NzaWJpbGl0eSB0byBhY3Jvc3MgYW5vdGhlciBQTUQuIERvIEkg bWlzcyBzb21ldGhpbmc/Cj4gPgo+ID5Mb29rIGF0IHRoZSBkZWZpbml0aW9uIG9mIHAqX2FkZHJf ZW5kKCkgdGhhdCBhcmUgdXNlZCB3aGVuIHBhZ2UgdGFibGVzCj4gPmFyZSByb2xsZWQgdXAuCj4g Pgo+IAo+IFNvcnJ5LCBJIGRvbid0IGdldCB5b3VyIHBvaW50Lgo+IAo+IFdoYXQncyB0aGUgbWVh bmluZyBvZiAicm9sbCB1cCIgaGVyZT8KPiAKPiBXb3VsZCB5b3UgbWluZCBnaXZpbmcgbWUgYW4g ZXhhbXBsZT8gSSBzZWUgcG1kX2FkZHJfZW5kKCkgaXMgbm90IHVzZWQgaW4gbWFueQo+IHBsYWNl cyBpbiBjb3JlIGtlcm5lbC4gQnkgZ2xhbmNpbmcgdGhvc2UgdXNhZ2VzLCBhbGwgdGhlIHBsYWNl cyB1c2UgaXQgbGlrZQo+IHBtZF9hZGRyX2VuZChhZGRyLCBlbmQpLiBTZWVtcyBubyBzcGVjaWFs bHkgaGFuZGluZyBvbiB0aGUgZW5kIGFkZHJlc3MuCj4gCj4gT3IgeW91IG1lYW4gdGhlIGNhc2Ug d2hlbiBwbWRfYWRkcl9lbmQoKSBpcyBkZWZpbmVkIHRvIHJldHVybiAiZW5kIiBkaXJlY3RseT8g CgpOb3QgYWxsIGhhcmR3YXJlIGhhcyBmaXZlIGxldmVscyBvZiBwYWdlIHRhYmxlcy4gIFdoZW4g aGFyZHdhcmUgZG9lcyBub3QKaGF2ZSBmaXZlIGxldmVscywgaXQgaXMgY29tbW9uIHRvICJyb2xs IHVwIiBzb21lIG9mIHRoZSBwYWdlIHRhYmxlcyBpbnRvCm90aGVycy4KClRoZXJlIGFyZSBnZW5l cmljIHdheXMgdG8gaW1wbGVtZW50IHRoaXMsIHdoaWNoIGluY2x1ZGUgdXNpbmc6CgppbmNsdWRl L2FzbS1nZW5lcmljL3BndGFibGUtbm9wNGQuaAppbmNsdWRlL2FzbS1nZW5lcmljL3BndGFibGUt bm9wdWQuaAppbmNsdWRlL2FzbS1nZW5lcmljL3BndGFibGUtbm9wbWQuaAoKYW5kIHRoZW4gdGhl cmUncyBhcmNoaXRlY3R1cmUgd2F5cyB0byBpbXBsZW1lbnQgdGhpcy4gIDMyLWJpdCBBUk0gdGFr ZXMKaXRzIGltcGxlbWVudGF0aW9uIGZvciBQTUQgbm90IGZyb20gdGhlIGdlbmVyaWMgdmVyc2lv biwgd2hpY2gKcG9zdC1kYXRlcyAzMi1iaXQgQVJNLCBidXQgZnJvbSBob3cgcGFnZSB0YWJsZSBy b2xsLXVwIHdhcyBpbXBsZW1lbnRlZApiYWNrIGF0IHRoZSB0aW1lIHdoZW4gdGhlIGN1cnJlbnQg QVJNIHNjaGVtZSB3YXMgZGV2aXNlZC4gIFRoZSBnZW5lcmljCnNjaGVtZSBpcyB1bnN1aXRhYmxl IGZvciAzMi1iaXQgQVJNIHNpbmNlIHdlIGRvIG1vcmUgdGhhbiBqdXN0IHJvbGwtdXAKcGFnZSB0 YWJsZXMsIGJ1dCB0aGlzIGlzIGlycmVsZXZlbnQgZm9yIHRoaXMgZGlzY3Vzc2lvbi4KCkFsbCB0 aHJlZSBvZiB0aGUgZ2VuZXJpYyBpbXBsZW1lbnRhdGlvbnMsIGFuZCAzMi1iaXQgQVJNLCBkZWZp bmUgdGhlCnBYWF9hZGRyX2VuZCgpIG1hY3JvcyB0aHVzbHk6CgppbmNsdWRlL2FzbS1nZW5lcmlj L3BndGFibGUtbm9wNGQuaDojZGVmaW5lIHA0ZF9hZGRyX2VuZChhZGRyLCBlbmQpIChlbmQpCmlu Y2x1ZGUvYXNtLWdlbmVyaWMvcGd0YWJsZS1ub3BtZC5oOiNkZWZpbmUgcG1kX2FkZHJfZW5kKGFk ZHIsIGVuZCkgKGVuZCkKaW5jbHVkZS9hc20tZ2VuZXJpYy9wZ3RhYmxlLW5vcHVkLmg6I2RlZmlu ZSBwdWRfYWRkcl9lbmQoYWRkciwgZW5kKSAoZW5kKQphcmNoL2FybS9pbmNsdWRlL2FzbS9wZ3Rh YmxlLTJsZXZlbC5oOiNkZWZpbmUgcG1kX2FkZHJfZW5kKGFkZHIsZW5kKSAoZW5kKQoKc2luY2Us IGFzIEkgc3RhdGVkLCBwWFhfYWRkcl9lbmQoKSBleHBlY3RzIGl0cyAiZW5kIiBhcmd1bWVudCB0 byBiZQp0aGUgYWRkcmVzcyBpbmRleCBvZiB0aGUgbmV4dCBlbnRyeSBpbiB0aGUgaW1tZWRpYXRl bHkgdXBwZXIgcGFnZQp0YWJsZSBsZXZlbCwgb3IgdGhlIGFkZHJlc3MgaW5kZXggb2YgdGhlIGxh c3QgZW50cnkgd2Ugd2lzaCB0bwpwcm9jZXNzLCB3aGljaCBldmVyIGlzIHNtYWxsZXIuCgpJZiBp dCdzIGxhcmdlciB0aGFuIHRoZSBhZGRyZXNzIGluZGV4IG9mIHRoZSBuZXh0IGVudHJ5IGluIHRo ZQppbW1lZGlhdGVseSB1cHBlciBwYWdlIHRhYmxlIGxldmVsLCB0aGVuIHRoZSBlZmZlY3Qgb2Yg YWxsIHRoZXNlCm1hY3JvcyB3aWxsIGJlIHRvIHdhbGsgb2ZmIHRoZSBlbmQgb2YgdGhlIGN1cnJl bnQgbGV2ZWwgb2YgcGFnZQp0YWJsZS4KClRvIHNlZSBob3cgdGhleSBfc2hvdWxkXyBiZSB1c2Vk LCBzZWUgdGhlIGxvb3BzIGluIGZyZWVfcGdkX3JhbmdlKCkKYW5kIHRoZSBmcmVlX3BYWF9yYW5n ZSgpIGZ1bmN0aW9ucyBjYWxsZWQgZnJvbSB0aGVyZSBhbmQgYmVsb3cuCgpJbiBhbGwgY2FzZXMg d2hlbiB0aGUgcFhYX2FkZHJfZW5kKCkgbWFjcm8gd2FzIGludHJvZHVjZWQsIHdoYXQgSSBzdGF0 ZQphYm92ZSBob2xkcyB0cnVlIC0gYW5kIEkgYmVsaWV2ZSBzdGlsbCBob2xkcyB0cnVlIHRvZGF5 LCB1bnRpbCB0aGlzCnBhdGNoIHRoYXQgaGFzIHJlcG9ydGVkbHkgY2F1c2VkIGlzc3Vlcy4KCi0t IApSTUsncyBQYXRjaCBzeXN0ZW06IGh0dHBzOi8vd3d3LmFybWxpbnV4Lm9yZy51ay9kZXZlbG9w ZXIvcGF0Y2hlcy8KRlRUQyBicm9hZGJhbmQgZm9yIDAuOG1pbGUgbGluZSBpbiBzdWJ1cmJpYTog c3luYyBhdCAxMi4xTWJwcyBkb3duIDYyMmticHMgdXAKQWNjb3JkaW5nIHRvIHNwZWVkdGVzdC5u ZXQ6IDExLjlNYnBzIGRvd24gNTAwa2JwcyB1cAoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgt YXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3Jn L21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= 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.1 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,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 9727BC35240 for ; Thu, 30 Jan 2020 14:15:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4C6FD2082E for ; Thu, 30 Jan 2020 14:15:42 +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="gZUm7KU4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C6FD2082E 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 D6B7D6B035C; Thu, 30 Jan 2020 09:15:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CF71D6B035D; Thu, 30 Jan 2020 09:15:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B96C56B035E; Thu, 30 Jan 2020 09:15:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id 9F4406B035C for ; Thu, 30 Jan 2020 09:15:41 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6639833C4 for ; Thu, 30 Jan 2020 14:15:41 +0000 (UTC) X-FDA: 76434498882.17.card11_6bbf84a9d0f5a X-HE-Tag: card11_6bbf84a9d0f5a X-Filterd-Recvd-Size: 8579 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Jan 2020 14:15:40 +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=gX6hyt20QV23hW9BRxe2F20Xz12H4clKTdo4rjaVKBc=; b=gZUm7KU4jFD/ciDCawzCmQ4Qk BbhLC8I4sZQXvUmlzEilMB1DVfY3XM3xypcYqkiLSIJOeNRHBJLlXy1+SttaI9bOTE4tqilqEUTp3 zuwGWZDR4DrnNm2V16/SirM6jMaoTXTqQ/14Fk5HuHvbogzgsSGkEOaDFKhH57y9KJB2N8cd6rIwk 4iIlgmchckGeFZjvrlcJJawcO/0Fsb/5KD5oJUSFEUSGEmR8zSn0fU5HGTrvGr87HXpPkOSuywh0q 3doHTSTEUH+1o2SRqlk/y4CZyoPo+OTr17xSPuPx2WwmBGflMV3yQxpdmoFuSAPGdlTp8xI1dLMPV Yog7MvofQ==; Received: from shell.armlinux.org.uk ([2001:4d48:ad52:3201:5054:ff:fe00:4ec]:33698) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ixAb9-0003h7-6h; Thu, 30 Jan 2020 14:15:11 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1ixAb3-0004SG-Mt; Thu, 30 Jan 2020 14:15:05 +0000 Date: Thu, 30 Jan 2020 14:15:05 +0000 From: Russell King - ARM Linux admin To: Wei Yang Cc: Dmitry Osipenko , 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: <20200130141505.GK25745@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> <20200129094738.GE25745@shell.armlinux.org.uk> <20200129215745.GA20736@richard> <20200129232441.GI25745@shell.armlinux.org.uk> <20200130013000.GA5137@richard> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200130013000.GA5137@richard> 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 Thu, Jan 30, 2020 at 09:30:00AM +0800, Wei Yang wrote: > On Wed, Jan 29, 2020 at 11:24:41PM +0000, Russell King - ARM Linux admi= n wrote: > >On Thu, Jan 30, 2020 at 05:57:45AM +0800, Wei Yang wrote: > >> On Wed, Jan 29, 2020 at 09:47:38AM +0000, Russell King - ARM Linux a= dmin wrote: > >> >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_a= rea_struct *vma, > >> >> > =20 > >> >> > for (; old_addr < old_end; old_addr +=3D extent, new_addr +=3D= extent) { > >> >> > 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_ar= ea_struct *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:19= 0 > >> >>=20 > >> >> and eventually kernel hangs. > >> >>=20 > >> >> Git's bisection points to this patch and reverting it helps. Plea= se fix, > >> >> thanks in advance. > >> > > >> >The above is definitely wrong - pXX_addr_end() are designed to be u= sed > >> >with an address index within the pXX table table and the address in= dex > >> >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. > >> > > >>=20 > >> #define pmd_addr_end(addr, end) \ > >> ({ unsigned long __boundary =3D ((addr) + PMD_SIZE) & PMD_MASK; \ > >> (__boundary - 1 < (end) - 1)? __boundary: (end); \ > >> }) > >>=20 > >> If my understanding is correct, the definition here align the addr t= o next PMD > >> boundary or end. > >>=20 > >> I don't see the possibility to across another PMD. Do I miss somethi= ng? > > > >Look at the definition of p*_addr_end() that are used when page tables > >are rolled up. > > >=20 > Sorry, I don't get your point. >=20 > What's the meaning of "roll up" here? >=20 > Would you mind giving me an example? I see pmd_addr_end() is not used i= n many > places in core kernel. By glancing those usages, all the places use it = like > pmd_addr_end(addr, end). Seems no specially handing on the end address. >=20 > Or you mean the case when pmd_addr_end() is defined to return "end" dir= ectly?=20 Not all hardware has five levels of page tables. When hardware does not have five levels, it is common to "roll up" some of the page tables into others. There are generic ways to implement this, which include using: include/asm-generic/pgtable-nop4d.h include/asm-generic/pgtable-nopud.h include/asm-generic/pgtable-nopmd.h and then there's architecture ways to implement this. 32-bit ARM takes its implementation for PMD not from the generic version, which post-dates 32-bit ARM, but from how page table roll-up was implemented back at the time when the current ARM scheme was devised. The generic scheme is unsuitable for 32-bit ARM since we do more than just roll-up page tables, but this is irrelevent for this discussion. All three of the generic implementations, and 32-bit ARM, define the pXX_addr_end() macros thusly: include/asm-generic/pgtable-nop4d.h:#define p4d_addr_end(addr, end) (end) include/asm-generic/pgtable-nopmd.h:#define pmd_addr_end(addr, end) (end) include/asm-generic/pgtable-nopud.h:#define pud_addr_end(addr, end) (end) arch/arm/include/asm/pgtable-2level.h:#define pmd_addr_end(addr,end) (end= ) since, as I stated, pXX_addr_end() expects its "end" argument to be the address index of the next entry in the immediately upper page table level, or the address index of the last entry we wish to process, which ever is smaller. If it's larger than the address index of the next entry in the immediately upper page table level, then the effect of all these macros will be to walk off the end of the current level of page table. To see how they _should_ be used, see the loops in free_pgd_range() and the free_pXX_range() functions called from there and below. In all cases when the pXX_addr_end() macro was introduced, what I state above holds true - and I believe still holds true today, until this patch that has reportedly caused issues. --=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