From owner-svn-src-all@FreeBSD.ORG Thu Jul 31 04:35:50 2014 Return-Path: Delivered-To: svn-src-all@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 F3109C06; Thu, 31 Jul 2014 04:35:49 +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 B154E224C; Thu, 31 Jul 2014 04:35:49 +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 s6V4XHOe014049; Wed, 30 Jul 2014 23:35:47 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp2.rice.edu with ESMTP id 1nf7d804yd-1; Wed, 30 Jul 2014 23:35:47 -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 6158B500122; Wed, 30 Jul 2014 23:35:46 -0500 (CDT) Message-ID: <53D9C7A0.4010100@rice.edu> Date: Wed, 30 Jul 2014 23:35:44 -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> <53D960E9.50905@rice.edu> <53D9630A.5050500@FreeBSD.org> In-Reply-To: <53D9630A.5050500@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------010001050408000309070408" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.713890987064109 urlsuspect_oldscore=0.713890987064109 suspectscore=4 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.713890987064109 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-1407310058 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 04:35:50 -0000 This is a multi-part message in MIME format. --------------010001050408000309070408 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07/30/2014 16:26, Andreas Tobler wrote: > On 30.07.14 23:17, Alan Cox wrote: >> 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? > > iPhone sei Dank: > > http://people.freebsd.org/~andreast/r269134-1_panic.jpg Ok, this patch should fix both the original panic and the new one. They are two distinct problems. --------------010001050408000309070408 Content-Type: text/plain; charset=ISO-8859-15; name="mmu_oea64_fixes.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mmu_oea64_fixes.patch" SW5kZXg6IHBvd2VycGMvYWltL21tdV9vZWE2NC5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHBvd2Vy cGMvYWltL21tdV9vZWE2NC5jCShyZXZpc2lvbiAyNjkxMjcpCisrKyBwb3dlcnBjL2FpbS9t bXVfb2VhNjQuYwkod29ya2luZyBjb3B5KQpAQCAtMTA5MCw2ICsxMDkwLDcgQEAgbW9lYTY0 X3Vud2lyZShtbXVfdCBtbXUsIHBtYXBfdCBwbSwgdm1fb2Zmc2V0X3Qgc3YKIAlmb3IgKHB2 byA9IFJCX05GSU5EKHB2b190cmVlLCAmcG0tPnBtYXBfcHZvLCAma2V5KTsKIAkgICAgcHZv ICE9IE5VTEwgJiYgUFZPX1ZBRERSKHB2bykgPCBldmE7CiAJICAgIHB2byA9IFJCX05FWFQo cHZvX3RyZWUsICZwbS0+cG1hcF9wdm8sIHB2bykpIHsKKwkJcHQgPSBNT0VBNjRfUFZPX1RP X1BURShtbXUsIHB2byk7CiAJCWlmICgocHZvLT5wdm9fdmFkZHIgJiBQVk9fV0lSRUQpID09 IDApCiAJCQlwYW5pYygibW9lYTY0X3Vud2lyZTogcHZvICVwIGlzIG1pc3NpbmcgUFZPX1dJ UkVEIiwKIAkJCSAgICBwdm8pOwpAQCAtMTA5OCw3ICsxMDk5LDcgQEAgbW9lYTY0X3Vud2ly ZShtbXVfdCBtbXUsIHBtYXBfdCBwbSwgdm1fb2Zmc2V0X3Qgc3YKIAkJCXBhbmljKCJtb2Vh NjRfdW53aXJlOiBwdGUgJXAgaXMgbWlzc2luZyBMUFRFX1dJUkVEIiwKIAkJCSAgICAmcHZv LT5wdm9fcHRlLmxwdGUpOwogCQlwdm8tPnB2b19wdGUubHB0ZS5wdGVfaGkgJj0gfkxQVEVf V0lSRUQ7Ci0JCWlmICgocHQgPSBNT0VBNjRfUFZPX1RPX1BURShtbXUsIHB2bykpICE9IC0x KSB7CisJCWlmIChwdCAhPSAtMSkgewogCQkJLyoKIAkJCSAqIFRoZSBQVEUncyB3aXJlZCBh dHRyaWJ1dGUgaXMgbm90IGEgaGFyZHdhcmUKIAkJCSAqIGZlYXR1cmUsIHNvIHRoZXJlIGlz IG5vIG5lZWQgdG8gaW52YWxpZGF0ZSBhbnkgVExCCkBAIC0yMjc0LDcgKzIyNzUsOCBAQCBt b2VhNjRfcHZvX2VudGVyKG1tdV90IG1tdSwgcG1hcF90IHBtLCB1bWFfem9uZV90CiAJCWlm IChwdm8tPnB2b19wbWFwID09IHBtICYmIFBWT19WQUREUihwdm8pID09IHZhKSB7CiAJCQlp ZiAoKHB2by0+cHZvX3B0ZS5scHRlLnB0ZV9sbyAmIExQVEVfUlBHTikgPT0gcGEgJiYKIAkJ CSAgICAocHZvLT5wdm9fcHRlLmxwdGUucHRlX2xvICYgKExQVEVfTk9FWEVDIHwgTFBURV9Q UCkpCi0JCQkgICAgPT0gKHB0ZV9sbyAmIChMUFRFX05PRVhFQyB8IExQVEVfUFApKSkgewor CQkJICAgID09IChwdGVfbG8gJiAoTFBURV9OT0VYRUMgfCBMUFRFX1BQKSkgJiYKKwkJCSAg ICAoKHB2by0+cHZvX3ZhZGRyIF4gZmxhZ3MpICYgUFZPX1dJUkVEKSA9PSAwKSB7CiAJCQkg ICAgCWlmICghKHB2by0+cHZvX3B0ZS5scHRlLnB0ZV9oaSAmIExQVEVfVkFMSUQpKSB7CiAJ CQkJCS8qIFJlLWluc2VydCBpZiBzcGlsbGVkICovCiAJCQkJCWkgPSBNT0VBNjRfUFRFX0lO U0VSVChtbXUsIHB0ZWdpZHgsCg== --------------010001050408000309070408--