From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Yang Subject: Re: [PATCH 3/5] mm/mremap: use pmd_addr_end to calculate next in move_page_tables() Date: Fri, 31 Jan 2020 05:57:27 +0800 Message-ID: <20200130215727.GA11373@richard> 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> <20200130141505.GK25745@shell.armlinux.org.uk> Reply-To: Wei Yang Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: <20200130141505.GK25745-QEMnZ+CodIVURfEZ8mYm6t73F7V6hmMc@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Russell King - ARM Linux admin Cc: Wei Yang , 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 02:15:05PM +0000, Russell King - ARM Linux admin wrote: >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. > Thanks for your patience in explaining this for me. I got your point. This is my fault in understanding the 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 -- Wei Yang Help you, Help me 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 48AF3C2D0DB for ; Thu, 30 Jan 2020 21:57:26 +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 EB49D20708 for ; Thu, 30 Jan 2020 21:57:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JDccopFO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB49D20708 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com 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:Reply-To:List-Subscribe:List-Help: List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version: References:Message-ID:Subject:To:From:Date:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DdcqURbN4IxicpcUsufUZym3EDG2CNoXpfgRlf93dsA=; b=JDccopFOstwqcN aL7tk8ZAL2z8pXaHEPFTcQedYsCupla4c3POkjVVHB1/4wnkljsrgIh+gcnodgiec8ktqcunJ/fHl 4C2E+nEK8NXk0pEWRhfpzpi7RO80fMuovguDfRFjgjGuNaHZiRehDHkhJQFTtKhTamVqNukZZyTPZ PPj0J1MkmzNLb1ePpHfaMVkQrrZQcQefBLKE5ZCnsHM5XYTduotoFQOsjBCOnxfSf/B1vD1Cut3ez ecQoyVQX4y9UfI4MWl4u0oGFHrE8OnSd84frAn0ut4ONbzGeSS5N4CzLmsu+8pEFQNSHxcBikXHJN 4hkGk3P9C21NMZpZT8Rg==; 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 1ixHoP-0004zR-JW; Thu, 30 Jan 2020 21:57:21 +0000 Received: from mga07.intel.com ([134.134.136.100]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ixHoL-0004yS-Vr for linux-arm-kernel@lists.infradead.org; Thu, 30 Jan 2020 21:57:19 +0000 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2020 13:57:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,382,1574150400"; d="scan'208";a="233109286" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by orsmga006.jf.intel.com with ESMTP; 30 Jan 2020 13:57:12 -0800 Date: Fri, 31 Jan 2020 05:57:27 +0800 From: Wei Yang To: Russell King - ARM Linux admin Subject: Re: [PATCH 3/5] mm/mremap: use pmd_addr_end to calculate next in move_page_tables() Message-ID: <20200130215727.GA11373@richard> 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> <20200130141505.GK25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200130141505.GK25745@shell.armlinux.org.uk> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200130_135718_083912_CD7E2741 X-CRM114-Status: GOOD ( 25.03 ) 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: , Reply-To: Wei Yang 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 , Wei Yang , "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 T24gVGh1LCBKYW4gMzAsIDIwMjAgYXQgMDI6MTU6MDVQTSArMDAwMCwgUnVzc2VsbCBLaW5nIC0g QVJNIExpbnV4IGFkbWluIHdyb3RlOgo+T24gVGh1LCBKYW4gMzAsIDIwMjAgYXQgMDk6MzA6MDBB TSArMDgwMCwgV2VpIFlhbmcgd3JvdGU6Cj4+IE9uIFdlZCwgSmFuIDI5LCAyMDIwIGF0IDExOjI0 OjQxUE0gKzAwMDAsIFJ1c3NlbGwgS2luZyAtIEFSTSBMaW51eCBhZG1pbiB3cm90ZToKPj4gPk9u IFRodSwgSmFuIDMwLCAyMDIwIGF0IDA1OjU3OjQ1QU0gKzA4MDAsIFdlaSBZYW5nIHdyb3RlOgo+ PiA+PiBPbiBXZWQsIEphbiAyOSwgMjAyMCBhdCAwOTo0NzozOEFNICswMDAwLCBSdXNzZWxsIEtp bmcgLSBBUk0gTGludXggYWRtaW4gd3JvdGU6Cj4+ID4+ID5PbiBTdW4sIEphbiAyNiwgMjAyMCBh dCAwNTo0Nzo1N1BNICswMzAwLCBEbWl0cnkgT3NpcGVua28gd3JvdGU6Cj4+ID4+ID4+IDE4LjAx LjIwMjAgMDI6MjIsIFdlaSBZYW5nINC/0LjRiNC10YI6Cj4+ID4+ID4+ID4gVXNlIHRoZSBnZW5l cmFsIGhlbHBlciBpbnN0ZWFkIG9mIGRvIGl0IGJ5IGhhbmQuCj4+ID4+ID4+ID4gCj4+ID4+ID4+ ID4gU2lnbmVkLW9mZi1ieTogV2VpIFlhbmcgPHJpY2hhcmR3LnlhbmdAbGludXguaW50ZWwuY29t Pgo+PiA+PiA+PiA+IC0tLQo+PiA+PiA+PiA+ICBtbS9tcmVtYXAuYyB8IDcgKystLS0tLQo+PiA+ PiA+PiA+ICAxIGZpbGUgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCA1IGRlbGV0aW9ucygtKQo+ PiA+PiA+PiA+IAo+PiA+PiA+PiA+IGRpZmYgLS1naXQgYS9tbS9tcmVtYXAuYyBiL21tL21yZW1h cC5jCj4+ID4+ID4+ID4gaW5kZXggYzJhZjhiYTRiYTQzLi5hMjU4OTE0ZjNlZTEgMTAwNjQ0Cj4+ ID4+ID4+ID4gLS0tIGEvbW0vbXJlbWFwLmMKPj4gPj4gPj4gPiArKysgYi9tbS9tcmVtYXAuYwo+ PiA+PiA+PiA+IEBAIC0yNTMsMTEgKzI1Myw4IEBAIHVuc2lnbmVkIGxvbmcgbW92ZV9wYWdlX3Rh YmxlcyhzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKnZtYSwKPj4gPj4gPj4gPiAgCj4+ID4+ID4+ID4g IAlmb3IgKDsgb2xkX2FkZHIgPCBvbGRfZW5kOyBvbGRfYWRkciArPSBleHRlbnQsIG5ld19hZGRy ICs9IGV4dGVudCkgewo+PiA+PiA+PiA+ICAJCWNvbmRfcmVzY2hlZCgpOwo+PiA+PiA+PiA+IC0J CW5leHQgPSAob2xkX2FkZHIgKyBQTURfU0laRSkgJiBQTURfTUFTSzsKPj4gPj4gPj4gPiAtCQkv KiBldmVuIGlmIG5leHQgb3ZlcmZsb3dlZCwgZXh0ZW50IGJlbG93IHdpbGwgYmUgb2sgKi8KPj4g Pj4gPj4gPiArCQluZXh0ID0gcG1kX2FkZHJfZW5kKG9sZF9hZGRyLCBvbGRfZW5kKTsKPj4gPj4g Pj4gPiAgCQlleHRlbnQgPSBuZXh0IC0gb2xkX2FkZHI7Cj4+ID4+ID4+ID4gLQkJaWYgKGV4dGVu dCA+IG9sZF9lbmQgLSBvbGRfYWRkcikKPj4gPj4gPj4gPiAtCQkJZXh0ZW50ID0gb2xkX2VuZCAt IG9sZF9hZGRyOwo+PiA+PiA+PiA+ICAJCW9sZF9wbWQgPSBnZXRfb2xkX3BtZCh2bWEtPnZtX21t LCBvbGRfYWRkcik7Cj4+ID4+ID4+ID4gIAkJaWYgKCFvbGRfcG1kKQo+PiA+PiA+PiA+ICAJCQlj b250aW51ZTsKPj4gPj4gPj4gPiBAQCAtMzAxLDcgKzI5OCw3IEBAIHVuc2lnbmVkIGxvbmcgbW92 ZV9wYWdlX3RhYmxlcyhzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKnZtYSwKPj4gPj4gPj4gPiAgCj4+ ID4+ID4+ID4gIAkJaWYgKHB0ZV9hbGxvYyhuZXdfdm1hLT52bV9tbSwgbmV3X3BtZCkpCj4+ID4+ ID4+ID4gIAkJCWJyZWFrOwo+PiA+PiA+PiA+IC0JCW5leHQgPSAobmV3X2FkZHIgKyBQTURfU0la RSkgJiBQTURfTUFTSzsKPj4gPj4gPj4gPiArCQluZXh0ID0gcG1kX2FkZHJfZW5kKG5ld19hZGRy LCBuZXdfYWRkciArIGxlbik7Cj4+ID4+ID4+ID4gIAkJaWYgKGV4dGVudCA+IG5leHQgLSBuZXdf YWRkcikKPj4gPj4gPj4gPiAgCQkJZXh0ZW50ID0gbmV4dCAtIG5ld19hZGRyOwo+PiA+PiA+PiA+ ICAJCW1vdmVfcHRlcyh2bWEsIG9sZF9wbWQsIG9sZF9hZGRyLCBvbGRfYWRkciArIGV4dGVudCwg bmV3X3ZtYSwKPj4gPj4gPj4gPiAKPj4gPj4gPj4gCj4+ID4+ID4+IEhlbGxvIFdlaSwKPj4gPj4g Pj4gCj4+ID4+ID4+IFN0YXJ0aW5nIHdpdGggbmV4dC0yMDIwMDEyMiwgSSdtIHNlZWluZyB0aGUg Zm9sbG93aW5nIGluIEtNU0cgb24gTlZJRElBCj4+ID4+ID4+IFRlZ3JhIChBUk0zMik6Cj4+ID4+ ID4+IAo+PiA+PiA+PiAgIEJVRzogQmFkIHJzcy1jb3VudGVyIHN0YXRlIG1tOihwdHJ2YWwpIHR5 cGU6TU1fQU5PTlBBR0VTIHZhbDoxOTAKPj4gPj4gPj4gCj4+ID4+ID4+IGFuZCBldmVudHVhbGx5 IGtlcm5lbCBoYW5ncy4KPj4gPj4gPj4gCj4+ID4+ID4+IEdpdCdzIGJpc2VjdGlvbiBwb2ludHMg dG8gdGhpcyBwYXRjaCBhbmQgcmV2ZXJ0aW5nIGl0IGhlbHBzLiBQbGVhc2UgZml4LAo+PiA+PiA+ PiB0aGFua3MgaW4gYWR2YW5jZS4KPj4gPj4gPgo+PiA+PiA+VGhlIGFib3ZlIGlzIGRlZmluaXRl bHkgd3JvbmcgLSBwWFhfYWRkcl9lbmQoKSBhcmUgZGVzaWduZWQgdG8gYmUgdXNlZAo+PiA+PiA+ d2l0aCBhbiBhZGRyZXNzIGluZGV4IHdpdGhpbiB0aGUgcFhYIHRhYmxlIHRhYmxlIGFuZCB0aGUg YWRkcmVzcyBpbmRleAo+PiA+PiA+b2YgZWl0aGVyIHRoZSBsYXN0IGVudHJ5IGluIHRoZSBzYW1l IHBYWCB0YWJsZSBvciB0aGUgYmVnaW5uaW5nIG9mIHRoZQo+PiA+PiA+X25leHRfIHBYWCB0YWJs ZS4gIEFyYml0YXJ5IGVuZCBhZGRyZXNzIGluZGljaWVzIGFyZSBub3QgYWxsb3dlZC4KPj4gPj4g Pgo+PiA+PiAKPj4gPj4gI2RlZmluZSBwbWRfYWRkcl9lbmQoYWRkciwgZW5kKQkJCQkJCVwKPj4g Pj4gKHsJdW5zaWduZWQgbG9uZyBfX2JvdW5kYXJ5ID0gKChhZGRyKSArIFBNRF9TSVpFKSAmIFBN RF9NQVNLOwlcCj4+ID4+IAkoX19ib3VuZGFyeSAtIDEgPCAoZW5kKSAtIDEpPyBfX2JvdW5kYXJ5 OiAoZW5kKTsJCVwKPj4gPj4gfSkKPj4gPj4gCj4+ID4+IElmIG15IHVuZGVyc3RhbmRpbmcgaXMg Y29ycmVjdCwgdGhlIGRlZmluaXRpb24gaGVyZSBhbGlnbiB0aGUgYWRkciB0byBuZXh0IFBNRAo+ PiA+PiBib3VuZGFyeSBvciBlbmQuCj4+ID4+IAo+PiA+PiBJIGRvbid0IHNlZSB0aGUgcG9zc2li aWxpdHkgdG8gYWNyb3NzIGFub3RoZXIgUE1ELiBEbyBJIG1pc3Mgc29tZXRoaW5nPwo+PiA+Cj4+ ID5Mb29rIGF0IHRoZSBkZWZpbml0aW9uIG9mIHAqX2FkZHJfZW5kKCkgdGhhdCBhcmUgdXNlZCB3 aGVuIHBhZ2UgdGFibGVzCj4+ID5hcmUgcm9sbGVkIHVwLgo+PiA+Cj4+IAo+PiBTb3JyeSwgSSBk b24ndCBnZXQgeW91ciBwb2ludC4KPj4gCj4+IFdoYXQncyB0aGUgbWVhbmluZyBvZiAicm9sbCB1 cCIgaGVyZT8KPj4gCj4+IFdvdWxkIHlvdSBtaW5kIGdpdmluZyBtZSBhbiBleGFtcGxlPyBJIHNl ZSBwbWRfYWRkcl9lbmQoKSBpcyBub3QgdXNlZCBpbiBtYW55Cj4+IHBsYWNlcyBpbiBjb3JlIGtl cm5lbC4gQnkgZ2xhbmNpbmcgdGhvc2UgdXNhZ2VzLCBhbGwgdGhlIHBsYWNlcyB1c2UgaXQgbGlr ZQo+PiBwbWRfYWRkcl9lbmQoYWRkciwgZW5kKS4gU2VlbXMgbm8gc3BlY2lhbGx5IGhhbmRpbmcg b24gdGhlIGVuZCBhZGRyZXNzLgo+PiAKPj4gT3IgeW91IG1lYW4gdGhlIGNhc2Ugd2hlbiBwbWRf YWRkcl9lbmQoKSBpcyBkZWZpbmVkIHRvIHJldHVybiAiZW5kIiBkaXJlY3RseT8gCj4KPk5vdCBh bGwgaGFyZHdhcmUgaGFzIGZpdmUgbGV2ZWxzIG9mIHBhZ2UgdGFibGVzLiAgV2hlbiBoYXJkd2Fy ZSBkb2VzIG5vdAo+aGF2ZSBmaXZlIGxldmVscywgaXQgaXMgY29tbW9uIHRvICJyb2xsIHVwIiBz b21lIG9mIHRoZSBwYWdlIHRhYmxlcyBpbnRvCj5vdGhlcnMuCj4KPlRoZXJlIGFyZSBnZW5lcmlj IHdheXMgdG8gaW1wbGVtZW50IHRoaXMsIHdoaWNoIGluY2x1ZGUgdXNpbmc6Cj4KPmluY2x1ZGUv YXNtLWdlbmVyaWMvcGd0YWJsZS1ub3A0ZC5oCj5pbmNsdWRlL2FzbS1nZW5lcmljL3BndGFibGUt bm9wdWQuaAo+aW5jbHVkZS9hc20tZ2VuZXJpYy9wZ3RhYmxlLW5vcG1kLmgKPgo+YW5kIHRoZW4g dGhlcmUncyBhcmNoaXRlY3R1cmUgd2F5cyB0byBpbXBsZW1lbnQgdGhpcy4gIDMyLWJpdCBBUk0g dGFrZXMKPml0cyBpbXBsZW1lbnRhdGlvbiBmb3IgUE1EIG5vdCBmcm9tIHRoZSBnZW5lcmljIHZl cnNpb24sIHdoaWNoCj5wb3N0LWRhdGVzIDMyLWJpdCBBUk0sIGJ1dCBmcm9tIGhvdyBwYWdlIHRh YmxlIHJvbGwtdXAgd2FzIGltcGxlbWVudGVkCj5iYWNrIGF0IHRoZSB0aW1lIHdoZW4gdGhlIGN1 cnJlbnQgQVJNIHNjaGVtZSB3YXMgZGV2aXNlZC4gIFRoZSBnZW5lcmljCj5zY2hlbWUgaXMgdW5z dWl0YWJsZSBmb3IgMzItYml0IEFSTSBzaW5jZSB3ZSBkbyBtb3JlIHRoYW4ganVzdCByb2xsLXVw Cj5wYWdlIHRhYmxlcywgYnV0IHRoaXMgaXMgaXJyZWxldmVudCBmb3IgdGhpcyBkaXNjdXNzaW9u Lgo+Cj5BbGwgdGhyZWUgb2YgdGhlIGdlbmVyaWMgaW1wbGVtZW50YXRpb25zLCBhbmQgMzItYml0 IEFSTSwgZGVmaW5lIHRoZQo+cFhYX2FkZHJfZW5kKCkgbWFjcm9zIHRodXNseToKPgo+aW5jbHVk ZS9hc20tZ2VuZXJpYy9wZ3RhYmxlLW5vcDRkLmg6I2RlZmluZSBwNGRfYWRkcl9lbmQoYWRkciwg ZW5kKSAoZW5kKQo+aW5jbHVkZS9hc20tZ2VuZXJpYy9wZ3RhYmxlLW5vcG1kLmg6I2RlZmluZSBw bWRfYWRkcl9lbmQoYWRkciwgZW5kKSAoZW5kKQo+aW5jbHVkZS9hc20tZ2VuZXJpYy9wZ3RhYmxl LW5vcHVkLmg6I2RlZmluZSBwdWRfYWRkcl9lbmQoYWRkciwgZW5kKSAoZW5kKQo+YXJjaC9hcm0v aW5jbHVkZS9hc20vcGd0YWJsZS0ybGV2ZWwuaDojZGVmaW5lIHBtZF9hZGRyX2VuZChhZGRyLGVu ZCkgKGVuZCkKPgo+c2luY2UsIGFzIEkgc3RhdGVkLCBwWFhfYWRkcl9lbmQoKSBleHBlY3RzIGl0 cyAiZW5kIiBhcmd1bWVudCB0byBiZQo+dGhlIGFkZHJlc3MgaW5kZXggb2YgdGhlIG5leHQgZW50 cnkgaW4gdGhlIGltbWVkaWF0ZWx5IHVwcGVyIHBhZ2UKPnRhYmxlIGxldmVsLCBvciB0aGUgYWRk cmVzcyBpbmRleCBvZiB0aGUgbGFzdCBlbnRyeSB3ZSB3aXNoIHRvCj5wcm9jZXNzLCB3aGljaCBl dmVyIGlzIHNtYWxsZXIuCj4KPklmIGl0J3MgbGFyZ2VyIHRoYW4gdGhlIGFkZHJlc3MgaW5kZXgg b2YgdGhlIG5leHQgZW50cnkgaW4gdGhlCj5pbW1lZGlhdGVseSB1cHBlciBwYWdlIHRhYmxlIGxl dmVsLCB0aGVuIHRoZSBlZmZlY3Qgb2YgYWxsIHRoZXNlCj5tYWNyb3Mgd2lsbCBiZSB0byB3YWxr IG9mZiB0aGUgZW5kIG9mIHRoZSBjdXJyZW50IGxldmVsIG9mIHBhZ2UKPnRhYmxlLgo+Cj5UbyBz ZWUgaG93IHRoZXkgX3Nob3VsZF8gYmUgdXNlZCwgc2VlIHRoZSBsb29wcyBpbiBmcmVlX3BnZF9y YW5nZSgpCj5hbmQgdGhlIGZyZWVfcFhYX3JhbmdlKCkgZnVuY3Rpb25zIGNhbGxlZCBmcm9tIHRo ZXJlIGFuZCBiZWxvdy4KPgo+SW4gYWxsIGNhc2VzIHdoZW4gdGhlIHBYWF9hZGRyX2VuZCgpIG1h Y3JvIHdhcyBpbnRyb2R1Y2VkLCB3aGF0IEkgc3RhdGUKPmFib3ZlIGhvbGRzIHRydWUgLSBhbmQg SSBiZWxpZXZlIHN0aWxsIGhvbGRzIHRydWUgdG9kYXksIHVudGlsIHRoaXMKPnBhdGNoIHRoYXQg aGFzIHJlcG9ydGVkbHkgY2F1c2VkIGlzc3Vlcy4KPgoKVGhhbmtzIGZvciB5b3VyIHBhdGllbmNl IGluIGV4cGxhaW5pbmcgdGhpcyBmb3IgbWUuCgpJIGdvdCB5b3VyIHBvaW50LiBUaGlzIGlzIG15 IGZhdWx0IGluIHVuZGVyc3RhbmRpbmcgdGhlIGNvZGUuCgo+LS0gCj5STUsncyBQYXRjaCBzeXN0 ZW06IGh0dHBzOi8vd3d3LmFybWxpbnV4Lm9yZy51ay9kZXZlbG9wZXIvcGF0Y2hlcy8KPkZUVEMg YnJvYWRiYW5kIGZvciAwLjhtaWxlIGxpbmUgaW4gc3VidXJiaWE6IHN5bmMgYXQgMTIuMU1icHMg ZG93biA2MjJrYnBzIHVwCj5BY2NvcmRpbmcgdG8gc3BlZWR0ZXN0Lm5ldDogMTEuOU1icHMgZG93 biA1MDBrYnBzIHVwCgotLSAKV2VpIFlhbmcKSGVscCB5b3UsIEhlbHAgbWUKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFp bGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlz dHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK 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.2 required=3.0 tests=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 A7F4BC33CB3 for ; Thu, 30 Jan 2020 21:57:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6817D20CC7 for ; Thu, 30 Jan 2020 21:57:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6817D20CC7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 051336B0392; Thu, 30 Jan 2020 16:57:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F1F426B0393; Thu, 30 Jan 2020 16:57:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBD486B0394; Thu, 30 Jan 2020 16:57:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0074.hostedemail.com [216.40.44.74]) by kanga.kvack.org (Postfix) with ESMTP id C11EA6B0392 for ; Thu, 30 Jan 2020 16:57:18 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7B9482DFC for ; Thu, 30 Jan 2020 21:57:18 +0000 (UTC) X-FDA: 76435662156.05.vest32_3fb19c473a260 X-HE-Tag: vest32_3fb19c473a260 X-Filterd-Recvd-Size: 8155 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Jan 2020 21:57:17 +0000 (UTC) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2020 13:57:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,382,1574150400"; d="scan'208";a="233109286" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by orsmga006.jf.intel.com with ESMTP; 30 Jan 2020 13:57:12 -0800 Date: Fri, 31 Jan 2020 05:57:27 +0800 From: Wei Yang To: Russell King - ARM Linux admin Cc: Wei Yang , 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: <20200130215727.GA11373@richard> Reply-To: Wei Yang 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> <20200130141505.GK25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200130141505.GK25745@shell.armlinux.org.uk> User-Agent: Mutt/1.9.4 (2018-02-28) 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 02:15:05PM +0000, Russell King - ARM Linux admin = wrote: >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 adm= in 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 =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_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_a= rea_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_vm= a, >> >> >> >=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:1= 90 >> >> >>=20 >> >> >> and eventually kernel hangs. >> >> >>=20 >> >> >> Git's bisection points to this patch and reverting it helps. Ple= ase 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 i= ndex >> >> >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 = to next PMD >> >> boundary or end. >> >>=20 >> >> I don't see the possibility to across another PMD. Do I miss someth= ing? >> > >> >Look at the definition of p*_addr_end() that are used when page table= s >> >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 = 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= . >>=20 >> Or you mean the case when pmd_addr_end() is defined to return "end" di= rectly?=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) (en= d) > >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. > Thanks for your patience in explaining this for me. I got your point. This is my fault in understanding the 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 622kb= ps up >According to speedtest.net: 11.9Mbps down 500kbps up --=20 Wei Yang Help you, Help me