From owner-svn-src-head@FreeBSD.ORG Wed Jul 30 21:17:33 2014 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC8EE322; Wed, 30 Jul 2014 21:17:32 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D0A02655; Wed, 30 Jul 2014 21:17:32 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s6ULGt15022860; Wed, 30 Jul 2014 16:17:30 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp2.rice.edu with ESMTP id 1nf7d801n8-1; Wed, 30 Jul 2014 16:17:30 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id A0AE8500119; Wed, 30 Jul 2014 16:17:29 -0500 (CDT) Message-ID: <53D960E9.50905@rice.edu> Date: Wed, 30 Jul 2014 16:17:29 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andreas Tobler , Alan Cox , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r269134 - head/sys/vm References: <201407261810.s6QIAIIj049439@svn.freebsd.org> <53D9406A.3060101@FreeBSD.org> <53D94BAF.8050102@rice.edu> <53D94D73.3050808@rice.edu> <53D95265.9010406@FreeBSD.org> In-Reply-To: <53D95265.9010406@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=1.05876107880931e-09 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.714301145562988 urlsuspect_oldscore=0.714301145562988 suspectscore=4 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.714301145562988 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407300244 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 21:17:33 -0000 On 07/30/2014 15:15, Andreas Tobler wrote: > On 30.07.14 21:54, Alan Cox wrote: >> On 07/30/2014 14:46, Alan Cox wrote: >>> On 07/30/2014 13:58, Andreas Tobler wrote: >>>> Hi Alan, >>>> >>>> On 26.07.14 20:10, Alan Cox wrote: >>>>> Author: alc >>>>> Date: Sat Jul 26 18:10:18 2014 >>>>> New Revision: 269134 >>>>> URL: http://svnweb.freebsd.org/changeset/base/269134 >>>>> >>>>> Log: >>>>> When unwiring a region of an address space, do not assume that >>>>> the >>>>> underlying physical pages are mapped by the pmap. If, for >>>>> example, the >>>>> application has performed an mprotect(..., PROT_NONE) on any part >>>>> of the >>>>> wired region, then those pages will no longer be mapped by the >>>>> pmap. >>>>> So, using the pmap to lookup the wired pages in order to >>>>> unwire them >>>>> doesn't always work, and when it doesn't work wired pages are >>>>> leaked. >>>>> >>>>> To avoid the leak, introduce and use a new function >>>>> vm_object_unwire() >>>>> that locates the wired pages by traversing the object and its >>>>> backing >>>>> objects. >>>>> >>>>> At the same time, switch from using pmap_change_wiring() to the >>>>> recently >>>>> introduced function pmap_unwire() for unwiring the region's >>>>> mappings. >>>>> pmap_unwire() is faster, because it operates a range of virtual >>>>> addresses >>>>> rather than a single virtual page at a time. Moreover, by >>>>> operating on >>>>> a range, it is superpage friendly. It doesn't waste time >>>>> performing >>>>> unnecessary demotions. >>>>> >>>>> Reported by: markj >>>>> Reviewed by: kib >>>>> Tested by: pho, jmg (arm) >>>>> Sponsored by: EMC / Isilon Storage Division >>>> This commit brings my 32- and 64-bit PowerMac's into panic. >>>> Unfortunately I'm not able to give you a backtrace in the form of a >>>> textdump nor of a core dump. >>>> >>>> The only thing I have is this picture: >>>> >>>> http://people.freebsd.org/~andreast/r269134_panic.jpg >>>> >>>> Exactly this revision gives a panic and breaks the textdump/coredump >>>> facility. >>>> >>>> How can I help debugging? >>>> >>> It appears to me that moea64_pvo_enter() had a pre-existing bug that >>> got >>> tickled by this change. Specifically, moea64_pvo_enter() doesn't set >>> the PVO_WIRED flag when an unwired mapping already exists. It just >>> returns with the mapping still in an unwired state. Consequently, when >>> pmap_unwire() finally runs, it doesn't find a wired mapping. >>> >>> Try this: >>> >>> Index: powerpc/aim/mmu_oea64.c >>> =================================================================== >>> --- powerpc/aim/mmu_oea64.c (revision 269127) >>> +++ powerpc/aim/mmu_oea64.c (working copy) >>> @@ -2274,7 +2274,8 @@ moea64_pvo_enter(mmu_t mmu, pmap_t pm, uma_zone_t >>> if (pvo->pvo_pmap == pm && PVO_VADDR(pvo) == va) { >>> if ((pvo->pvo_pte.lpte.pte_lo & LPTE_RPGN) >>> == pa && >>> (pvo->pvo_pte.lpte.pte_lo & (LPTE_NOEXEC | >>> LPTE_PP)) >>> - == (pte_lo & (LPTE_NOEXEC | LPTE_PP))) { >>> + == (pte_lo & (LPTE_NOEXEC | LPTE_PP)) && >>> + ((pvo->pvo_vaddr ^ flags) & PVO_WIRED)) { >>> if (!(pvo->pvo_pte.lpte.pte_hi & >>> LPTE_VALID)) { >>> /* Re-insert if spilled */ >>> i = MOEA64_PTE_INSERT(mmu, >>> ptegidx, >>> >> >> The new conditional test needs to be inverted. Try this instead: >> >> Index: powerpc/aim/mmu_oea64.c >> =================================================================== >> --- powerpc/aim/mmu_oea64.c (revision 269127) >> +++ powerpc/aim/mmu_oea64.c (working copy) >> @@ -2274,7 +2274,8 @@ moea64_pvo_enter(mmu_t mmu, pmap_t pm, uma_zone_t >> if (pvo->pvo_pmap == pm && PVO_VADDR(pvo) == va) { >> if ((pvo->pvo_pte.lpte.pte_lo & LPTE_RPGN) >> == pa && >> (pvo->pvo_pte.lpte.pte_lo & (LPTE_NOEXEC | >> LPTE_PP)) >> - == (pte_lo & (LPTE_NOEXEC | LPTE_PP))) { >> + == (pte_lo & (LPTE_NOEXEC | LPTE_PP)) && >> + ((pvo->pvo_vaddr ^ flags) & PVO_WIRED) == >> 0) { >> if (!(pvo->pvo_pte.lpte.pte_hi & >> LPTE_VALID)) { >> /* Re-insert if spilled */ >> i = MOEA64_PTE_INSERT(mmu, >> ptegidx, >> > > > The panic stays, but the message is different: > > panic: moea64_pvo_to_pte: pvo 0x10147ea0 has invalid pte 0xb341180 in > moea64_pteg_table but valid in pvo. > My attempted fix is doing something else wrong. Do you have a stack trace?