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