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.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_PASS,T_DKIMWL_WL_HIGH 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 4F627C004C9 for ; Tue, 7 May 2019 17:19:38 +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 20D9C206BF for ; Tue, 7 May 2019 17:19:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="kuUC0kSE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 20D9C206BF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Subject:References: In-Reply-To:Message-ID: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=ITeupuwto1mWz+RV04V8zEdtKeTyCo4ZBCx5u+rCl/o=; b=kuUC0kSE6N7C63 6f0J9/WCFvhhYCYGz+fNue4Ea8C2Nnnk2R04ayQPX6eksqdDVX2fizkE0SD2O4pBJFSIhR1NTNizA 4AqDvCooC02/FYRIT94/oozslpwyYTS7HgN1AEO6d/kuPCR3yPjHMHyp9X/uiH6HZOFFAkaNfQDr4 gUuloCtbKWaDezxGoaBI74wz/77UmRQG41/bQ57nDIZaEQaXqGUkIq/FwkQOjBu/WkM3CTQOVQs5H dHsdSE5RRufbNs+PFEFw0CyLkjOJv/KyJn96wOiQN6ZI/GG2fsPglbEfYAesrXn1X0QoJF5cJJDBt gbUvATE7o4unWIDshSWw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hO3kc-0007UM-N7; Tue, 07 May 2019 17:19:34 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hO3kX-0007Sn-TK for linux-arm-kernel@lists.infradead.org; Tue, 07 May 2019 17:19:32 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F31E32DA99A; Tue, 7 May 2019 17:19:28 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E0F74608CA; Tue, 7 May 2019 17:19:28 +0000 (UTC) Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 7E3783FB10; Tue, 7 May 2019 17:19:28 +0000 (UTC) Date: Tue, 7 May 2019 13:19:28 -0400 (EDT) From: Jan Stancek To: Yang Shi Message-ID: <2058828796.21479120.1557249568244.JavaMail.zimbra@redhat.com> In-Reply-To: <3d0843fa-1a34-1d5a-ca4d-abe4032bad8b@linux.alibaba.com> References: <1817839533.20996552.1557065445233.JavaMail.zimbra@redhat.com> <1928544225.21255545.1557178548494.JavaMail.zimbra@redhat.com> <2b2006bf-753b-c4b8-e9a2-fd27ae65fe14@linux.alibaba.com> <756571293.21386229.1557229889545.JavaMail.zimbra@redhat.com> <3d0843fa-1a34-1d5a-ca4d-abe4032bad8b@linux.alibaba.com> Subject: Re: [bug] aarch64: userspace stalls on page fault after dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") MIME-Version: 1.0 X-Originating-IP: [10.40.204.177, 10.4.195.25] Thread-Topic: aarch64: userspace stalls on page fault after dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") Thread-Index: gKpt2e16SeHI5yEAfB9u2ttX2c306w== X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 07 May 2019 17:19:29 +0000 (UTC) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190507_101929_990878_D01897DA X-CRM114-Status: GOOD ( 40.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrea Arcangeli , Rik van Riel , vbabka@suse.cz, catalin marinas , will deacon , willy@infradead.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Waiman Long , kirill@shutemov.name, akpm@linux-foundation.org, Mel Gorman , Jan Stancek , kirill shutemov 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 Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiAKPiAKPiBPbiA1LzcvMTkgNDo1MSBBTSwg SmFuIFN0YW5jZWsgd3JvdGU6Cj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gPj4K PiA+PiBPbiA1LzYvMTkgMjozNSBQTSwgSmFuIFN0YW5jZWsgd3JvdGU6Cj4gPj4+IC0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiA+Pj4+IE9uIDUvNS8xOSA3OjEwIEFNLCBKYW4gU3RhbmNl ayB3cm90ZToKPiA+Pj4+PiBIaSwKPiA+Pj4+Pgo+ID4+Pj4+IEknbSBzZWVpbmcgdXNlcnNwYWNl IHByb2dyYW0gZ2V0dGluZyBzdHVjayBvbiBhYXJjaDY0LCBvbiBrZXJuZWxzIDQuMjAKPiA+Pj4+ PiBhbmQKPiA+Pj4+PiBuZXdlci4KPiA+Pj4+PiBJdCBzdGFsbHMgZnJvbSBzZWNvbmRzIHRvIGhv dXJzLgo+ID4+Pj4+Cj4gPj4+Pj4gSSBoYXZlIHNpbXBsaWZpZWQgaXQgdG8gZm9sbG93aW5nIHNj ZW5hcmlvIChyZXByb2R1Y2VyIGxpbmtlZCBiZWxvdwo+ID4+Pj4+IFsxXSk6Cj4gPj4+Pj4gICAg ICB3aGlsZSAoMSk6Cj4gPj4+Pj4gICAgICAgIHNwYXduIFRocmVhZCAxOiBtbWFwLCB3cml0ZSwg bXVubWFwCj4gPj4+Pj4gICAgICAgIHNwYXduIFRocmVhZCAyOiA8bm90aGluZz4KPiA+Pj4+Pgo+ ID4+Pj4+IFRocmVhZCAxIGlzIHNwb3JhZGljYWxseSBnZXR0aW5nIHN0dWNrIG9uIHdyaXRlIHRv IG1hcHBlZCBhcmVhLgo+ID4+Pj4+IFVzZXItc3BhY2UKPiA+Pj4+PiBpcyBub3QKPiA+Pj4+PiBt b3ZpbmcgZm9yd2FyZCAtIHN0ZG91dCBvdXRwdXQgc3RvcHMuIE9ic2VydmVkIENQVSB1c2FnZSBp cyBob3dldmVyCj4gPj4+Pj4gMTAwJS4KPiA+Pj4+Pgo+ID4+Pj4+IEF0IHRoaXMgdGltZSwga2Vy bmVsIGFwcGVhcnMgdG8gYmUgYnVzeSBoYW5kbGluZyBwYWdlIGZhdWx0cyAofjcwMGsgcGVyCj4g Pj4+Pj4gc2Vjb25kKToKPiA+Pj4+Pgo+ID4+Pj4+ICMgcGVyZiB0b3AgLWEgLWcKPiA+Pj4+PiAt ICAgOTguOTclICAgICA4LjMwJSAgYS5vdXQgICAgICAgICAgICAgICAgICAgICBbLl0gbWFwX3dy aXRlX3VubWFwCj4gPj4+Pj4gICAgICAgLSAyMy41MiUgbWFwX3dyaXRlX3VubWFwCj4gPj4+Pj4g ICAgICAgICAgLSAyNC4yOSUgZWwwX3N5bmMKPiA+Pj4+PiAgICAgICAgICAgICAtIDEwLjQyJSBk b19tZW1fYWJvcnQKPiA+Pj4+PiAgICAgICAgICAgICAgICAtIDE3LjgxJSBkb190cmFuc2xhdGlv bl9mYXVsdAo+ID4+Pj4+ICAgICAgICAgICAgICAgICAgIC0gMzMuMDElIGRvX3BhZ2VfZmF1bHQK PiA+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAtIDU2LjE4JSBoYW5kbGVfbW1fZmF1bHQKPiA+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIDQwLjI2JSBfX2hhbmRsZV9tbV9mYXVsdAo+ ID4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgMi4xOSUgX19sbF9zY19fX2NtcHhjaGdf Y2FzZV9hY3FfNAo+ID4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgMC44NyUgbWVtX2Nn cm91cF9mcm9tX3Rhc2sKPiA+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAtIDYuMTglIGZpbmRf dm1hCj4gPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICA1LjM4JSB2bWFjYWNoZV9maW5k Cj4gPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAxLjM1JSBfX2xsX3NjX19fY21weGNoZ19j YXNlX2FjcV84Cj4gPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAxLjIzJSBfX2xsX3NjX2F0 b21pYzY0X3N1Yl9yZXR1cm5fcmVsZWFzZQo+ID4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg MC43OCUgZG93bl9yZWFkX3RyeWxvY2sKPiA+Pj4+PiAgICAgICAgICAgICAgIDAuOTMlIGRvX3Ry YW5zbGF0aW9uX2ZhdWx0Cj4gPj4+Pj4gICAgICAgKyA4LjMwJSB0aHJlYWRfc3RhcnQKPiA+Pj4+ Pgo+ID4+Pj4+ICMgIHBlcmYgc3RhdCAtcCA4MTg5IC1kCj4gPj4+Pj4gXkMKPiA+Pj4+PiAgICAg UGVyZm9ybWFuY2UgY291bnRlciBzdGF0cyBmb3IgcHJvY2VzcyBpZCAnODE4OSc6Cj4gPj4+Pj4K PiA+Pj4+PiAgICAgICAgICAgIDk4NC4zMTEzNTAgICAgICB0YXNrLWNsb2NrIChtc2VjKSAgICAg ICAgICMgICAgMS4wMDAgQ1BVcwo+ID4+Pj4+ICAgICAgICAgICAgdXRpbGl6ZWQKPiA+Pj4+PiAg ICAgICAgICAgICAgICAgICAgIDAgICAgICBjb250ZXh0LXN3aXRjaGVzICAgICAgICAgICMgICAg MC4wMDAgSy9zZWMKPiA+Pj4+PiAgICAgICAgICAgICAgICAgICAgIDAgICAgICBjcHUtbWlncmF0 aW9ucyAgICAgICAgICAgICMgICAgMC4wMDAgSy9zZWMKPiA+Pj4+PiAgICAgICAgICAgICAgIDcy Myw2NDEgICAgICBwYWdlLWZhdWx0cyAgICAgICAgICAgICAgICMgICAgMC43MzUgTS9zZWMKPiA+ Pj4+PiAgICAgICAgIDIsNTU5LDE5OSw0MzQgICAgICBjeWNsZXMgICAgICAgICAgICAgICAgICAg ICMgICAgMi42MDAgR0h6Cj4gPj4+Pj4gICAgICAgICAgIDcxMSw5MzMsMTEyICAgICAgaW5zdHJ1 Y3Rpb25zICAgICAgICAgICAgICAjICAgIDAuMjggIGluc24KPiA+Pj4+PiAgICAgICAgICAgcGVy Cj4gPj4+Pj4gICAgICAgICAgIGN5Y2xlCj4gPj4+Pj4gICAgICAgPG5vdCBzdXBwb3J0ZWQ+ICAg ICAgYnJhbmNoZXMKPiA+Pj4+PiAgICAgICAgICAgICAgIDc1Nyw2NTggICAgICBicmFuY2gtbWlz c2VzCj4gPj4+Pj4gICAgICAgICAgIDIwNSw4NDAsNTU3ICAgICAgTDEtZGNhY2hlLWxvYWRzICAg ICAgICAgICAjICAyMDkuMTIxIE0vc2VjCj4gPj4+Pj4gICAgICAgICAgICA0MCw1NjEsNTI5ICAg ICAgTDEtZGNhY2hlLWxvYWQtbWlzc2VzICAgICAjICAgMTkuNzElIG9mIGFsbAo+ID4+Pj4+ICAg ICAgICAgICAgTDEtZGNhY2hlIGhpdHMKPiA+Pj4+PiAgICAgICA8bm90IHN1cHBvcnRlZD4gICAg ICBMTEMtbG9hZHMKPiA+Pj4+PiAgICAgICA8bm90IHN1cHBvcnRlZD4gICAgICBMTEMtbG9hZC1t aXNzZXMKPiA+Pj4+Pgo+ID4+Pj4+ICAgICAgICAgICAwLjk4NDQ1NDg5MiBzZWNvbmRzIHRpbWUg ZWxhcHNlZAo+ID4+Pj4+Cj4gPj4+Pj4gV2l0aCBzb21lIGV4dHJhIHRyYWNlcywgaXQgYXBwZWFy cyBsb29waW5nIGluIHBhZ2UgZmF1bHQgZm9yIHNhbWUKPiA+Pj4+PiBhZGRyZXNzLAo+ID4+Pj4+ IG92ZXIgYW5kIG92ZXI6Cj4gPj4+Pj4gICAgICBkb19wYWdlX2ZhdWx0IC8vIG1tX2ZsYWdzOiAw eDU1Cj4gPj4+Pj4gICAgICAgIF9fZG9fcGFnZV9mYXVsdAo+ID4+Pj4+ICAgICAgICAgIF9faGFu ZGxlX21tX2ZhdWx0Cj4gPj4+Pj4gICAgICAgICAgICBoYW5kbGVfcHRlX2ZhdWx0Cj4gPj4+Pj4g ICAgICAgICAgICAgIHB0ZXBfc2V0X2FjY2Vzc19mbGFncwo+ID4+Pj4+ICAgICAgICAgICAgICAg IGlmIChwdGVfc2FtZShwdGUsIGVudHJ5KSkgIC8vIHB0ZTogZTgwMDA4MDUwNjBmNTMsCj4gPj4+ Pj4gICAgICAgICAgICAgICAgZW50cnk6Cj4gPj4+Pj4gICAgICAgICAgICAgICAgZTgwMDA4MDUw NjBmNTMKPiA+Pj4+Pgo+ID4+Pj4+IEkgaGFkIHRyYWNlcyBpbiBtbWFwKCkgYW5kIG11bm1hcCgp IGFzIHdlbGwsIHRoZXkgZG9uJ3QgZ2V0IGhpdCB3aGVuCj4gPj4+Pj4gcmVwcm9kdWNlcgo+ID4+ Pj4+IGhpdHMgdGhlIGJhZCBzdGF0ZS4KPiA+Pj4+Pgo+ID4+Pj4+IE5vdGVzOgo+ID4+Pj4+IC0g SSdtIG5vdCBhYmxlIHRvIHJlcHJvZHVjZSB0aGlzIG9uIHg4Ni4KPiA+Pj4+PiAtIEF0dGFjaGlu ZyBHREIgb3Igc3RyYWNlIGltbWVkaWF0ZWxseSByZWNvdmVycyBhcHBsaWNhdGlvbiBmcm9tIHN0 YWxsLgo+ID4+Pj4+IC0gSXQgYWxzbyBzZWVtcyB0byByZWNvdmVyIGZhc3RlciB3aGVuIHN5c3Rl bSBpcyBidXN5IHdpdGggb3RoZXIgdGFza3MuCj4gPj4+Pj4gLSBNQVBfU0hBUkVEIHZzLiBNQVBf UFJJVkFURSBtYWtlcyBubyBkaWZmZXJlbmNlLgo+ID4+Pj4+IC0gVHVybmluZyBvZmYgVEhQIG1h a2VzIG5vIGRpZmZlcmVuY2UuCj4gPj4+Pj4gLSBSZXByb2R1Y2VyIFsxXSB1c3VhbGx5IGhpdHMg aXQgd2l0aGluIH5taW51dGUgb24gSFcgZGVzY3JpYmVkIGJlbG93Lgo+ID4+Pj4+IC0gTG9uZ21h biBtZW50aW9uZWQgdGhhdCAiV2hlbiB0aGUgcndzZW0gYmVjb21lcyByZWFkZXItb3duZWQsIGl0 Cj4gPj4+Pj4gY2F1c2VzCj4gPj4+Pj4gICAgICBhbGwgdGhlIHNwaW5uaW5nIHdyaXRlcnMgdG8g Z28gdG8gc2xlZXAgYWRkaW5nIHdha2V1cCBsYXRlbmN5IHRvCj4gPj4+Pj4gICAgICB0aGUgdGlt ZSByZXF1aXJlZCB0byBmaW5pc2ggdGhlIGNyaXRpY2FsIHNlY3Rpb25zIiwgYnV0IHRoaXMgbG9v a3MKPiA+Pj4+PiAgICAgIGxpa2UgYnVzeSBsb29wLCBzbyBJJ20gbm90IHN1cmUgaWYgaXQncyBy ZWxhdGVkIHRvIHJ3c2VtIGlzc3Vlcwo+ID4+Pj4+ICAgICAgaWRlbnRpZmllZAo+ID4+Pj4+ICAg ICAgaW46Cj4gPj4+Pj4gICAgICBodHRwczovL2xvcmUua2VybmVsLm9yZy9sa21sLzIwMTkwNDI4 MjEyNTU3LjEzNDgyLTItbG9uZ21hbkByZWRoYXQuY29tLwo+ID4+Pj4gSXQgc291bmRzIHBvc3Np YmxlIHRvIG1lLiBXaGF0IHRoZSBvcHRpbWl6YXRpb24gZG9uZSBieSB0aGUgY29tbWl0ICgibW06 Cj4gPj4+PiBtbWFwOiB6YXAgcGFnZXMgd2l0aCByZWFkIG1tYXBfc2VtIGluIG11bm1hcCIpIGlz IHRvIGRvd25ncmFkZSB3cml0ZQo+ID4+Pj4gcndzZW0gdG8gcmVhZCB3aGVuIHphcHBpbmcgcGFn ZXMgYW5kIHBhZ2UgdGFibGUgaW4gbXVubWFwKCkgYWZ0ZXIgdGhlCj4gPj4+PiB2bWFzIGhhdmUg YmVlbiBkZXRhY2hlZCBmcm9tIHRoZSByYnRyZWUuCj4gPj4+Pgo+ID4+Pj4gU28gdGhlIG1tYXAo KSwgd2hpY2ggaXMgd3JpdGVyLCBpbiB5b3VyIHRlc3QgbWF5IHN0ZWFsIHRoZSBsb2NrIGFuZAo+ ID4+Pj4gZXhlY3V0ZSB3aXRoIHRoZSBtdW5tYXAoKSwgd2hpY2ggaXMgdGhlIHJlYWRlciBhZnRl ciB0aGUgZG93bmdyYWRlLCBpbgo+ID4+Pj4gcGFyYWxsZWwgdG8gYnJlYWsgdGhlIG11dHVhbCBl eGNsdXNpb24uCj4gPj4+Pgo+ID4+Pj4gSW4gdGhpcyBjYXNlLCB0aGUgcGFyYWxsZWwgbW1hcCgp IG1heSBtYXAgdG8gdGhlIHNhbWUgYXJlYSBzaW5jZSB2bWFzCj4gPj4+PiBoYXZlIGJlZW4gZGV0 YWNoZWQgYnkgbXVubWFwKCksIHRoZW4gbW1hcCgpIG1heSBjcmVhdGUgdGhlIGNvbXBsZXRlIHNh bWUKPiA+Pj4+IHZtYXMsIGFuZCBwYWdlIGZhdWx0IGhhcHBlbnMgb24gdGhlIHNhbWUgdm1hIGF0 IHRoZSBzYW1lIGFkZHJlc3MuCj4gPj4+Pgo+ID4+Pj4gSSdtIG5vdCBzdXJlIHdoeSBnZGIgb3Ig c3RyYWNlIGNvdWxkIHJlY292ZXIgdGhpcywgYnV0IHRoZXkgdXNlIHB0cmFjZQo+ID4+Pj4gd2hp Y2ggbWF5IGFjcXVpcmUgbW1hcF9zZW0gdG8gYnJlYWsgdGhlIHBhcmFsbGVsIGluYWR2ZXJ0ZW50 bHkuCj4gPj4+Pgo+ID4+Pj4gTWF5IHlvdSBwbGVhc2UgdHJ5IFdhaW1hbidzIHBhdGNoIHRvIHNl ZSBpZiBpdCBtYWtlcyBhbnkgZGlmZmVyZW5jZT8KPiA+Pj4gSSBkb24ndCBzZWUgYW55IGRpZmZl cmVuY2UgaW4gYmVoYXZpb3VyIGFmdGVyIGFwcGx5aW5nOgo+ID4+PiAgICAgW1BBVENILXRpcCB2 NyAwMS8yMF0gbG9ja2luZy9yd3NlbTogUHJldmVudCBkZWNyZW1lbnQgb2YgcmVhZGVyIGNvdW50 Cj4gPj4+ICAgICBiZWZvcmUgaW5jcmVtZW50Cj4gPj4+IElzc3VlIGlzIHN0aWxsIGVhc2lseSBy ZXByb2R1Y2libGUgZm9yIG1lLgo+ID4+Pgo+ID4+PiBJJ20gaW5jbHVkaW5nIG91dHB1dCBvZiBt ZW1fYWJvcnRfZGVjb2RlKCkgLyBzaG93X3B0ZSgpIGZvciBzYW1wbGUgUFRFLAo+ID4+PiB0aGF0 Cj4gPj4+IEkgc2VlIGluIHBhZ2UgZmF1bHQgbG9vcC4gKEkgd2VudCB0aHJvdWdoIGFsbCBiaXRz LCBidXQgY291bGRuJ3QgZmluZAo+ID4+PiBhbnl0aGluZyBpbnZhbGlkIGFib3V0IGl0KQo+ID4+ Pgo+ID4+PiAgICAgbWVtX2Fib3J0X2RlY29kZTogTWVtIGFib3J0IGluZm86Cj4gPj4+ICAgICBt ZW1fYWJvcnRfZGVjb2RlOiAgIEVTUiA9IDB4OTIwMDAwNDcKPiA+Pj4gICAgIG1lbV9hYm9ydF9k ZWNvZGU6ICAgRXhjZXB0aW9uIGNsYXNzID0gREFCVCAobG93ZXIgRUwpLCBJTCA9IDMyIGJpdHMK PiA+Pj4gICAgIG1lbV9hYm9ydF9kZWNvZGU6ICAgU0VUID0gMCwgRm5WID0gMAo+ID4+PiAgICAg bWVtX2Fib3J0X2RlY29kZTogICBFQSA9IDAsIFMxUFRXID0gMAo+ID4+PiAgICAgbWVtX2Fib3J0 X2RlY29kZTogRGF0YSBhYm9ydCBpbmZvOgo+ID4+PiAgICAgbWVtX2Fib3J0X2RlY29kZTogICBJ U1YgPSAwLCBJU1MgPSAweDAwMDAwMDQ3Cj4gPj4+ICAgICBtZW1fYWJvcnRfZGVjb2RlOiAgIENN ID0gMCwgV25SID0gMQo+ID4+PiAgICAgc2hvd19wdGU6IHVzZXIgcGd0YWJsZTogNjRrIHBhZ2Vz LCA0OC1iaXQgVkFzLCBwZ2RwID0KPiA+Pj4gICAgIDAwMDAwMDAwNjcwMjc1NjcKPiA+Pj4gICAg IHNob3dfcHRlOiBbMDAwMGZmZmY2ZGZmMDAwMF0gcGdkPTAwMDAwMDE3NmJhZTAwMDMKPiA+Pj4g ICAgIHNob3dfcHRlOiAsIHB1ZD0wMDAwMDAxNzZiYWUwMDAzCj4gPj4+ICAgICBzaG93X3B0ZTog LCBwbWQ9MDAwMDAwMTc0YWQ2MDAwMwo+ID4+PiAgICAgc2hvd19wdGU6ICwgcHRlPTAwZTgwMDA4 MDIzYTBmNTMKPiA+Pj4gICAgIHNob3dfcHRlOiAsIHB0ZV9wZm46IDgwMjNhCj4gPj4+Cj4gPj4+ ICAgICA+Pj4gcHJpbnQgYmluKDB4NDcpCj4gPj4+ICAgICAwYjEwMDAxMTEKPiA+Pj4KPiA+Pj4g ICAgIFBlciBEMTItMjc3OSAoQVJNIEFyY2hpdGVjdHVyZSBSZWZlcmVuY2UgTWFudWFsKSwKPiA+ Pj4gICAgICAgICBJU1MgZW5jb2RpbmcgZm9yIGFuIGV4Y2VwdGlvbiBmcm9tIGFuIEluc3RydWN0 aW9uIEFib3J0Ogo+ID4+PiAgICAgICBJRlNDLCBiaXRzIFs1OjBdLCBJbnN0cnVjdGlvbiBGYXVs dCBTdGF0dXMgQ29kZQo+ID4+PiAgICAgICAwYjAwMDExMSBUcmFuc2xhdGlvbiBmYXVsdCwgbGV2 ZWwgMwo+ID4+Pgo+ID4+PiAtLS0KPiA+Pj4KPiA+Pj4gTXkgdGhlb3J5IGlzIHRoYXQgVExCIGlz IGdldHRpbmcgYnJva2VuLgo+ID4gVGhlb3J5IGNvbnRpbnVlZDoKPiA+Cj4gPiB1bm1hcF9yZWdp b24oKSBpcyBiYXRjaGluZyB1cGRhdGVzIHRvIFRMQiAoZm9yIHZtYXMgYW5kIHBhZ2UgdGFibGVz KS4KPiA+IEFuZCBhdCB0aGUgc2FtZSB0aW1lIGFub3RoZXIgdGhyZWFkIGhhbmRsZXMgcGFnZSBm YXVsdCBmb3Igc2FtZSBtbSwKPiA+IHdoaWNoIGluY3JlYXNlcyAidGxiX2ZsdXNoX3BlbmRpbmci Lgo+ID4KPiA+IHRsYl9maW5pc2hfbW11KCkgY2FsbGVkIGZyb20gdW5tYXBfcmVnaW9uKCkgd2ls bCB0aHVzIHNldCAnZm9yY2UgPSAxJy4KPiA+IEFuZCBhcmNoX3RsYl9maW5pc2hfbW11KCkgd2ls bCBpbiB0dXJuIHJlc2V0IFRMQiByYW5nZSwgcHJlc3VtYWJseSBtYWtpbmcKPiA+IGl0IHNtYWxs ZXIgdGhlbiBpdCB3b3VsZCBiZSBpZiBmb3JjZSA9PSAwLgo+ID4KPiA+IENoYW5nZSBiZWxvdyBh cHBlYXJzIHRvIGZpeCBpdDoKPiA+Cj4gPiBkaWZmIC0tZ2l0IGEvbW0vbW11X2dhdGhlci5jIGIv bW0vbW11X2dhdGhlci5jCj4gPiBpbmRleCBmMmYwM2M2NTU4MDcuLmE0Y2VmMjFiZDYyYiAxMDA2 NDQKPiA+IC0tLSBhL21tL21tdV9nYXRoZXIuYwo+ID4gKysrIGIvbW0vbW11X2dhdGhlci5jCj4g PiBAQCAtOTMsNyArOTMsNyBAQCB2b2lkIGFyY2hfdGxiX2ZpbmlzaF9tbXUoc3RydWN0IG1tdV9n YXRoZXIgKnRsYiwKPiA+ICAgICAgICAgIHN0cnVjdCBtbXVfZ2F0aGVyX2JhdGNoICpiYXRjaCwg Km5leHQ7Cj4gPiAgIAo+ID4gICAgICAgICAgaWYgKGZvcmNlKSB7Cj4gPiAtICAgICAgICAgICAg ICAgX190bGJfcmVzZXRfcmFuZ2UodGxiKTsKPiA+ICAgICAgICAgICAgICAgICAgX190bGJfYWRq dXN0X3JhbmdlKHRsYiwgc3RhcnQsIGVuZCAtIHN0YXJ0KTsKPiAKPiBJIGRvbid0IGdldCB3aHkg dGhlIGNoYW5nZSBjb3VsZCBmaXggaXQ/CgpNeSBndWVzcyBpcyB0aGF0IHJlc2V0IGNsZWFycyAi dGxiLT5mcmVlZF90YWJsZXMiLCB3aGljaCBjaGFuZ2VzIGhvdwp0bGJfZmx1c2goKSBvcGVyYXRl cywgc2VlICJib29sIGxhc3RfbGV2ZWwgPSAhdGxiLT5mcmVlZF90YWJsZXM7IiBpbgphcmNoL2Fy bTY0L2luY2x1ZGUvYXNtL3RsYi5oLiBNYXliZSB0aGF0IGRvZXNuJ3QgY2xlYXIgc29tZSBpbnRl cm1lZGlhdGUKZW50cmllcz8gTm8gY2x1ZS4KCklmIEkgbGV0IGl0IHJlc2V0IHRoZSByYW5nZSwg YnV0IHByZXNlcnZlICJmcmVlZF90YWJsZXMiLCBpdCBhbHNvCnNlZW1zIHRvIHNvbHZlIHRoZSBw cm9ibGVtOgoKZGlmZiAtLWdpdCBhL21tL21tdV9nYXRoZXIuYyBiL21tL21tdV9nYXRoZXIuYwpp bmRleCBmMmYwM2M2NTU4MDcuLjE3ZmIwZDdlZGMwMyAxMDA2NDQKLS0tIGEvbW0vbW11X2dhdGhl ci5jCisrKyBiL21tL21tdV9nYXRoZXIuYwpAQCAtOTMsOCArOTMsMjAgQEAgdm9pZCBhcmNoX3Rs Yl9maW5pc2hfbW11KHN0cnVjdCBtbXVfZ2F0aGVyICp0bGIsCiAgICAgICAgc3RydWN0IG1tdV9n YXRoZXJfYmF0Y2ggKmJhdGNoLCAqbmV4dDsKIAogICAgICAgIGlmIChmb3JjZSkgewotICAgICAg ICAgICAgICAgX190bGJfcmVzZXRfcmFuZ2UodGxiKTsKKyAgICAgICAgICAgICAgIGlmICh0bGIt PmZ1bGxtbSkgeworICAgICAgICAgICAgICAgICAgICAgICB0bGItPnN0YXJ0ID0gdGxiLT5lbmQg PSB+MDsKKyAgICAgICAgICAgICAgIH0gZWxzZSB7CisgICAgICAgICAgICAgICAgICAgICAgIHRs Yi0+c3RhcnQgPSBUQVNLX1NJWkU7CisgICAgICAgICAgICAgICAgICAgICAgIHRsYi0+ZW5kID0g MDsKKyAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIF9fdGxiX2FkanVzdF9yYW5nZSh0 bGIsIHN0YXJ0LCBlbmQgLSBzdGFydCk7Cgo+IF9fdGxiX3Jlc2V0X3JhbmdlKCkganVzdCByZXNl dAo+IHN0YXJ0IGFuZCBlbmQgdG8gVEFTS19TSVpFIGFuZCAwLCB0aGVuIF9fdGxiX2FkanVzdF9y YW5nZSgpIHNldCBwcm9wZXIKPiBzdGFydCBhbmQgZW5kLiBJIGRvbid0IGdldCB3aHkgImZvcmNl IiBmbHVzaCBzbWFsbGVyIHJhbmdlPwoKSSdtIHN0aWxsIHRyeWluZyB0byB1bmRlcnN0YW5kIHRo aXMgcGFydC4gSXQncyBhY3R1YWxseSBub3Qgc21hbGxlciwgYnV0IGl0IGNoYW5nZXM6Cgp1bm1h cF9yZWdpb24oKQogICMgdm1fc3RhcnQ6IGZmZmY0OWJkMDAwMCB2bV9lbmQ6IGZmZmY0OWJlMDAw MAogIC4uLgogICMgdGxiLnN0YXJ0LCB0bGIuZW5kOiAxMDAwMDAwMDAwMDAwIDAKICBmcmVlX3Bn dGFibGVzKCkKICAjIHRsYi5zdGFydCwgdGxiLmVuZDogZmZmZjQwMDAwMDAwIGZmZmY0MDAxMDAw MAogIHRsYl9maW5pc2hfbW11KCkKICAgIGFyY2hfdGxiX2ZpbmlzaF9tbXUoKQogICAgICAjIHdp bGwgc2VlIGZvcmNlID09IDEKICAgICAgIyByZXNldHMgdGxiLnN0YXJ0LCB0bGIuZW5kIHRvOiBm ZmZmNDliZDAwMDAgZmZmZjQ5YmUwMDAwCgo+IAo+ID4gICAgICAgICAgfQo+ID4KPiA+Pj4gSSBt YWRlIGEgZHVtbXkga2VybmVsIG1vZHVsZSB0aGF0IGV4cG9ydHMgZGVidWdmcyBmaWxlLCB3aGlj aCBvbiByZWFkCj4gPj4+IHRyaWdnZXJzOgo+ID4+PiAgICAgZmx1c2hfdGxiX2FsbCgpOwo+ID4+ Pgo+ID4+PiBBbnkgdGltZSByZXByb2R1Y2VyIHN0YWxscyBhbmQgSSByZWFkIGRlYnVnZnMgZmls ZSwgaXQgcmVjb3ZlcnMKPiA+Pj4gaW1tZWRpYXRlbHkgYW5kIHJlc3VtZXMgcHJpbnRpbmcgdG8g c3Rkb3V0Lgo+ID4+IFRoYXQgY29tbWl0IGRvZXNuJ3QgY2hhbmdlIGFueXRoaW5nIGFib3V0IFRM QiBmbHVzaCwganVzdCBtb3ZlIHphcHBpbmcKPiA+PiBwYWdlcyB1bmRlciByZWFkIG1tYXBfc2Vt IGFzIHdoYXQgTUFEVl9ET05UTkVFRCBkb2VzLgo+ID4+Cj4gPj4gSSBkb24ndCBoYXZlIGFhcmNo NjQgYm9hcmQgdG8gcmVwcm9kdWNlIGFuZCBkZWJ1ZyBpdC4gQW5kLCBJJ20gbm90Cj4gPj4gZmFt aWxpYXIgd2l0aCBhYXJjaDY0IGFyY2hpdGVjdHVyZSBlaXRoZXIuIEJ1dCwgc29tZSBoaXN0b3J5 IHRvbGQgbWUgdGhlCj4gPj4gcGFyYWxsZWwgemFwcGluZyBwYWdlIG1heSBydW4gaW50byBzdGFs ZSBUTEIgYW5kIGRlZmVyIGEgZmx1c2ggbWVhbmluZwo+ID4+IHRoYXQgdGhpcyBjYWxsIG1heSBv YnNlcnZlIHB0ZV9ub25lIGFuZCBmYWlscyB0byBmbHVzaCB0aGUgVExCLiBCdXQsCj4gPj4gdGhp cyBoYXMgYmVlbiBzb2x2ZWQgYnkgY29tbWl0IDU2MjM2YTU5NTU2YyAoIm1tOiByZWZhY3RvciBU TEIgZ2F0aGVyaW5nCj4gPj4gQVBJIikgYW5kIDk5YmFhYzIxZTQ1OCAoIm1tOiBmaXggTUFEVl9b RlJFRXxET05UTkVFRF0gVExCIGZsdXNoIG1pc3MKPiA+PiBwcm9ibGVtIikuCj4gPj4KPiA+PiBG b3IgbW9yZSBkZXRhaWwsIHBsZWFzZSByZWZlciB0byBjb21taXQgNDY0NzcwNmViZWVlICgibW06 IGFsd2F5cyBmbHVzaAo+ID4+IFZNQSByYW5nZXMgYWZmZWN0ZWQgYnkgemFwX3BhZ2VfcmFuZ2Ui KS4gQ29waWVkIE1lbCBhbmQgUmlrIGluIHRoaXMKPiA+PiB0aHJlYWQuIEFsc28gYWRkZWQgV2ls bCBEZWFjb24gYW5kIENhdGFsaW4gTWFyaW5hcywgd2hvIGFyZSBhYXJjaDY0Cj4gPj4gbWFpbnRh aW5lcnMsIGluIHRoaXMgbG9vcAo+ID4gVGhhbmtzCj4gPgo+ID4+IEJ1dCwgeW91ciB0ZXN0ICh0 cmlnZ2VyaW5nIFRMQiBmbHVzaCkgZG9lcyBkZW1vbnN0cmF0ZSBUTEIgZmx1c2ggaXMKPiA+PiAq bm90KiBkb25lIHByb3Blcmx5IGF0IHNvbWUgcG9pbnQgYXMgZXhwZWN0ZWQgZm9yIGFhcmNoNjQu IENvdWxkIHlvdQo+ID4+IHBsZWFzZSBnaXZlIHRoZSBiZWxvdyBwYXRjaCBhIHRyeT8KPiA+IFlv dXIgcGF0Y2ggYWxzbyBmaXhlcyBteSByZXByb2R1Y2VyLgo+IAo+IFRoYW5rcyBmb3IgdGVzdGlu ZyBpdC4KPiAKPiA+Cj4gPj4gZGlmZiAtLWdpdCBhL21tL21lbW9yeS5jIGIvbW0vbWVtb3J5LmMK PiA+PiBpbmRleCBhYjY1MGMyLi5lZjQxYWQ1IDEwMDY0NAo+ID4+IC0tLSBhL21tL21lbW9yeS5j Cj4gPj4gKysrIGIvbW0vbWVtb3J5LmMKPiA+PiBAQCAtMTMzNiw4ICsxMzM2LDEwIEBAIHZvaWQg dW5tYXBfdm1hcyhzdHJ1Y3QgbW11X2dhdGhlciAqdGxiLAo+ID4+Cj4gPj4gICDCoMKgwqDCoMKg wqDCoCBtbXVfbm90aWZpZXJfcmFuZ2VfaW5pdCgmcmFuZ2UsIHZtYS0+dm1fbW0sIHN0YXJ0X2Fk ZHIsCj4gPj4gICDCoMKgwqDCoMKgwqDCoCBlbmRfYWRkcik7Cj4gPj4gICDCoMKgwqDCoMKgwqDC oCBtbXVfbm90aWZpZXJfaW52YWxpZGF0ZV9yYW5nZV9zdGFydCgmcmFuZ2UpOwo+ID4+IC3CoMKg wqDCoMKgwqAgZm9yICggOyB2bWEgJiYgdm1hLT52bV9zdGFydCA8IGVuZF9hZGRyOyB2bWEgPSB2 bWEtPnZtX25leHQpCj4gPj4gK8KgwqDCoMKgwqDCoCBmb3IgKCA7IHZtYSAmJiB2bWEtPnZtX3N0 YXJ0IDwgZW5kX2FkZHI7IHZtYSA9IHZtYS0+dm1fbmV4dCkgewo+ID4+ICAgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIHVubWFwX3NpbmdsZV92bWEodGxiLCB2bWEsIHN0YXJ0X2FkZHIs IGVuZF9hZGRyLCBOVUxMKTsKPiA+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBmbHVz aF90bGJfcmFuZ2Uodm1hLCBzdGFydF9hZGRyLCBlbmRfYWRkcik7Cj4gPj4gK8KgwqDCoMKgwqDC oCB9Cj4gPj4gICDCoMKgwqDCoMKgwqDCoCBtbXVfbm90aWZpZXJfaW52YWxpZGF0ZV9yYW5nZV9l bmQoJnJhbmdlKTsKPiA+PiAgIMKgfQo+ID4+Cj4gPj4+Pj4gLSBJIHRyaWVkIDIgZGlmZmVyZW50 IGFhcmNoNjQgc3lzdGVtcyBzbyBmYXI6IEFQTSBYLUdlbmUgQ1BVIFBvdGVuemEgQTMKPiA+Pj4+ PiBhbmQKPiA+Pj4+PiAgICAgIFF1YWxjb21tIDY1LUxBLTExNS0xNTEuCj4gPj4+Pj4gICAgICBJ IGNhbiByZXByb2R1Y2UgaXQgb24gYm90aCB3aXRoIHY1LjEtcmM3LiBJdCdzIGVhc2llciB0byBy ZXByb2R1Y2UKPiA+Pj4+PiAgICAgIG9uIGxhdHRlciBvbmUgKGZvciBsb25nZXIgcGVyaW9kcyBv ZiB0aW1lKSwgd2hpY2ggaGFzIDQ2IENQVXMuCj4gPj4+Pj4gLSBTYW1wbGUgb3V0cHV0IG9mIHJl cHJvZHVjZXIgb24gb3RoZXJ3aXNlIGlkbGUgc3lzdGVtOgo+ID4+Pj4+ICAgICAgIyAuL2Eub3V0 Cj4gPj4+Pj4gICAgICBbMDAwMDAzMTRdIG1hcF93cml0ZV91bm1hcCB0b29rOiAyNjMwNSBtcwo+ ID4+Pj4+ICAgICAgWzAwMDAwODY3XSBtYXBfd3JpdGVfdW5tYXAgdG9vazogMTM2NDIgbXMKPiA+ Pj4+PiAgICAgIFswMDAwMjIwMF0gbWFwX3dyaXRlX3VubWFwIHRvb2s6IDQ0MjM3IG1zCj4gPj4+ Pj4gICAgICBbMDAwMDI4NTFdIG1hcF93cml0ZV91bm1hcCB0b29rOiA5OTIgbXMKPiA+Pj4+PiAg ICAgIFswMDAwNDcyNV0gbWFwX3dyaXRlX3VubWFwIHRvb2s6IDU0MiBtcwo+ID4+Pj4+ICAgICAg WzAwMDA2NDQzXSBtYXBfd3JpdGVfdW5tYXAgdG9vazogNTMzMyBtcwo+ID4+Pj4+ICAgICAgWzAw MDA2NTkzXSBtYXBfd3JpdGVfdW5tYXAgdG9vazogMjExNjIgbXMKPiA+Pj4+PiAgICAgIFswMDAw NzQzNV0gbWFwX3dyaXRlX3VubWFwIHRvb2s6IDE2OTgyIG1zCj4gPj4+Pj4gICAgICBbMDAwMDc0 ODhdIG1hcF93cml0ZSB1bm1hcCB0b29rOiAxMyBtc15DCj4gPj4+Pj4KPiA+Pj4+PiBJIHJhbiBh IGJpc2VjdCwgd2hpY2ggaWRlbnRpZmllZCBmb2xsb3dpbmcgY29tbWl0IGFzIGZpcnN0IGJhZCBv bmU6Cj4gPj4+Pj4gICAgICBkZDIyODNmMjYwNWUgKCJtbTogbW1hcDogemFwIHBhZ2VzIHdpdGgg cmVhZCBtbWFwX3NlbSBpbiBtdW5tYXAiKQo+ID4+Pj4+Cj4gPj4+Pj4gSSBjYW4gYWxzbyBtYWtl IHRoZSBpc3N1ZSBnbyBhd2F5IHdpdGggZm9sbG93aW5nIGNoYW5nZToKPiA+Pj4+PiBkaWZmIC0t Z2l0IGEvbW0vbW1hcC5jIGIvbW0vbW1hcC5jCj4gPj4+Pj4gaW5kZXggMzMwZjEyYzE3ZmExLi4x M2NlNDY1NzQwZTIgMTAwNjQ0Cj4gPj4+Pj4gLS0tIGEvbW0vbW1hcC5jCj4gPj4+Pj4gKysrIGIv bW0vbW1hcC5jCj4gPj4+Pj4gQEAgLTI4NDQsNyArMjg0NCw3IEBAIEVYUE9SVF9TWU1CT0wodm1f bXVubWFwKTsKPiA+Pj4+PiAgICAgU1lTQ0FMTF9ERUZJTkUyKG11bm1hcCwgdW5zaWduZWQgbG9u ZywgYWRkciwgc2l6ZV90LCBsZW4pCj4gPj4+Pj4gICAgIHsKPiA+Pj4+PiAgICAgICAgICAgIHBy b2ZpbGVfbXVubWFwKGFkZHIpOwo+ID4+Pj4+IC0gICAgICAgcmV0dXJuIF9fdm1fbXVubWFwKGFk ZHIsIGxlbiwgdHJ1ZSk7Cj4gPj4+Pj4gKyAgICAgICByZXR1cm4gX192bV9tdW5tYXAoYWRkciwg bGVuLCBmYWxzZSk7Cj4gPj4+Pj4gICAgIH0KPiA+Pj4+Pgo+ID4+Pj4+ICMgY2F0IC9wcm9jL2Nw dWluZm8gIHwgaGVhZAo+ID4+Pj4+IHByb2Nlc3NvciAgICAgICA6IDAKPiA+Pj4+PiBCb2dvTUlQ UyAgICAgICAgOiA0MC4wMAo+ID4+Pj4+IEZlYXR1cmVzICAgICAgICA6IGZwIGFzaW1kIGV2dHN0 cm0gYWVzIHBtdWxsIHNoYTEgc2hhMiBjcmMzMiBjcHVpZAo+ID4+Pj4+IGFzaW1kcmRtCj4gPj4+ Pj4gQ1BVIGltcGxlbWVudGVyIDogMHg1MQo+ID4+Pj4+IENQVSBhcmNoaXRlY3R1cmU6IDgKPiA+ Pj4+PiBDUFUgdmFyaWFudCAgICAgOiAweDAKPiA+Pj4+PiBDUFUgcGFydCAgICAgICAgOiAweGMw MAo+ID4+Pj4+IENQVSByZXZpc2lvbiAgICA6IDEKPiA+Pj4+Pgo+ID4+Pj4+ICMgbnVtYWN0bCAt SAo+ID4+Pj4+IGF2YWlsYWJsZTogMSBub2RlcyAoMCkKPiA+Pj4+PiBub2RlIDAgY3B1czogMCAx IDIgMyA0IDUgNiA3IDggOSAxMCAxMSAxMiAxMyAxNCAxNSAxNiAxNyAxOCAxOSAyMCAyMSAyMgo+ ID4+Pj4+IDIzCj4gPj4+Pj4gMjQgMjUgMjYgMjcgMjggMjkgMzAgMzEgMzIgMzMgMzQgMzUgMzYg MzcgMzggMzkgNDAgNDEgNDIgNDMgNDQgNDUKPiA+Pj4+PiBub2RlIDAgc2l6ZTogOTc5MzggTUIK PiA+Pj4+PiBub2RlIDAgZnJlZTogOTU3MzIgTUIKPiA+Pj4+PiBub2RlIGRpc3RhbmNlczoKPiA+ Pj4+PiBub2RlICAgMAo+ID4+Pj4+ICAgICAgMDogIDEwCj4gPj4+Pj4KPiA+Pj4+PiBSZWdhcmRz LAo+ID4+Pj4+IEphbgo+ID4+Pj4+Cj4gPj4+Pj4gWzFdCj4gPj4+Pj4gaHR0cHM6Ly9naXRodWIu Y29tL2pzdGFuY2VrL3JlcHJvZHVjZXJzL2Jsb2IvbWFzdGVyL2tlcm5lbC9wYWdlX2ZhdWx0X3N0 YWxsL21tYXA1LmMKPiA+Pj4+PiBbMl0KPiA+Pj4+PiBodHRwczovL2dpdGh1Yi5jb20vanN0YW5j ZWsvcmVwcm9kdWNlcnMvYmxvYi9tYXN0ZXIva2VybmVsL3BhZ2VfZmF1bHRfc3RhbGwvY29uZmln Cj4gPj4KPiAKPiAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMu aW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2xpbnV4LWFybS1rZXJuZWwK 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.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_PASS 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 1BF3AC004C9 for ; Tue, 7 May 2019 17:19:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BED372054F for ; Tue, 7 May 2019 17:19:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BED372054F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 758B96B0007; Tue, 7 May 2019 13:19:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 709C66B0008; Tue, 7 May 2019 13:19:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D85D6B000A; Tue, 7 May 2019 13:19:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by kanga.kvack.org (Postfix) with ESMTP id 3898B6B0007 for ; Tue, 7 May 2019 13:19:31 -0400 (EDT) Received: by mail-qt1-f200.google.com with SMTP id o34so20056268qte.5 for ; Tue, 07 May 2019 10:19:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:date:from:to :cc:message-id:in-reply-to:references:subject:mime-version :content-transfer-encoding:thread-topic:thread-index; bh=8KF8hLUDZ1r4q++anmbOmMh7jGTsSiVj2+U3ICX6ng0=; b=YUzbqrG5C6RuQVQR4r9MfsghRtcEa/KKCHaw3fqTsiyeBzwdl41YKmmw/36nNaibD7 QVOj5AbkSKQdWQAZwYRDHnIvZSp5bup6EyMMtn8xnGX9lB567enw7xTwGzGnl67yLRug /YjkxXPb+EjnRMKEfjD+nYkEdD3yugII2/meWBHMCWbGqOa4FK/kMUEsTxXqJEYmy22D kOryNur3PSbwJW4LKkBjv1hnzEEk/CjsNOEHZ0M2ZiYwYcAo+QaCCvTsq0b5Ow/O37h3 GOQxzUsIFMi3IyjrL1I2kXtHrmv0XA2NYiZX7YHBo5ghMHKGToQL2fTk6DJeVwE+IRcX YHKw== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jstancek@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jstancek@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Gm-Message-State: APjAAAWdhD95eaVVk44Q8fcNupsQ49C89gKAA0V3IansgeUtqjieM7HY M5oy/0hD9tn0slrtaKwYZOtJ8PW7osdI4DbK1/WJZiv9hYjCxEXGZfuab1r37ZPyH9Quo6I89Qs u7ynLxypIP7knkr3i8MGlTYJ5dqk7WPn2YdhvLFrGhCmBoBvOjlfRBadvgmu577OQXQ== X-Received: by 2002:aed:3ffa:: with SMTP id w55mr28265794qth.142.1557249570920; Tue, 07 May 2019 10:19:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqxJNJjX89omStOg07uoO0YiHMWLzRev2J/4QI4JOMkqjEFNKdNwcP5Tup7Cr5QPmmAAkVXw X-Received: by 2002:aed:3ffa:: with SMTP id w55mr28265746qth.142.1557249569983; Tue, 07 May 2019 10:19:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557249569; cv=none; d=google.com; s=arc-20160816; b=oCJaEQQXqdrG3fxPYrYKU8Gf9jeZeQDE1sGIoGd68uCd1/PUuSsz6IZ3KXqFPNfkZS ffkkwOBIIFotwY9uWXag/p7DTKBa5nRimwswer7HEuGDCbVF98Ylv9L3H+zww28Gi/dn gSGaHAZJ+95b+9i/CZfhVdMXck0gM7bJr4ijIyDFzzZAAHLPZm1Xt/HHo6NTM2cG1s3e urYV5wq8p+47XGs8n6Id7n5BKlyokqnb7L7PoBSW0elU6KeXcKXV6GEJ91tqPOoicDTW 3YDlvT+74YkXJBBKw+bsyB6Ft/2PkHrvaa4rI7IrQWJCPSeYcv2EhyAYISGnXaIzkbXF wqBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=thread-index:thread-topic:content-transfer-encoding:mime-version :subject:references:in-reply-to:message-id:cc:to:from:date; bh=8KF8hLUDZ1r4q++anmbOmMh7jGTsSiVj2+U3ICX6ng0=; b=QwVoLI1/Xi4JaphJEhmoZ6JW6IJRCv9TfDdh/fCghPuQLlAZL7CcYueNmmA4y96zW5 8WTEzyB6nhGpoMBIkPicP2i7493mb+fSJVnsxY1lmeR83fOQs/OG8L9t5xfWZDL/J092 kzXQF9tIlyDf9ujqn0vOb7RkqwKE1AXPy7H6pcVJIhAfOtTe9uLDhC0B75jh3EV8DY1G saIIW6LQPLxsCGTVyVShIUAkH+Lukx5CvjpWS7H4D6K26SAxVQAif8mnjvVUCNpO5TO0 rLXH21z9FmkgLrxjp3MIiKP6IRl+GbBnBZ48le2N3X02DZlzbMn3lWmF40CBREm49aT9 taJQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of jstancek@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jstancek@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id d6si6955053qtj.292.2019.05.07.10.19.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 10:19:29 -0700 (PDT) Received-SPF: pass (google.com: domain of jstancek@redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; Authentication-Results: mx.google.com; spf=pass (google.com: domain of jstancek@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jstancek@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F31E32DA99A; Tue, 7 May 2019 17:19:28 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E0F74608CA; Tue, 7 May 2019 17:19:28 +0000 (UTC) Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 7E3783FB10; Tue, 7 May 2019 17:19:28 +0000 (UTC) Date: Tue, 7 May 2019 13:19:28 -0400 (EDT) From: Jan Stancek To: Yang Shi Cc: will deacon , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, kirill@shutemov.name, willy@infradead.org, kirill shutemov , vbabka@suse.cz, Andrea Arcangeli , akpm@linux-foundation.org, Waiman Long , Mel Gorman , Rik van Riel , catalin marinas , Jan Stancek Message-ID: <2058828796.21479120.1557249568244.JavaMail.zimbra@redhat.com> In-Reply-To: <3d0843fa-1a34-1d5a-ca4d-abe4032bad8b@linux.alibaba.com> References: <1817839533.20996552.1557065445233.JavaMail.zimbra@redhat.com> <1928544225.21255545.1557178548494.JavaMail.zimbra@redhat.com> <2b2006bf-753b-c4b8-e9a2-fd27ae65fe14@linux.alibaba.com> <756571293.21386229.1557229889545.JavaMail.zimbra@redhat.com> <3d0843fa-1a34-1d5a-ca4d-abe4032bad8b@linux.alibaba.com> Subject: Re: [bug] aarch64: userspace stalls on page fault after dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.40.204.177, 10.4.195.25] Thread-Topic: aarch64: userspace stalls on page fault after dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") Thread-Index: gKpt2e16SeHI5yEAfB9u2ttX2c306w== X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 07 May 2019 17:19:29 +0000 (UTC) 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: ----- Original Message ----- >=20 >=20 > On 5/7/19 4:51 AM, Jan Stancek wrote: > > ----- Original Message ----- > >> > >> On 5/6/19 2:35 PM, Jan Stancek wrote: > >>> ----- Original Message ----- > >>>> On 5/5/19 7:10 AM, Jan Stancek wrote: > >>>>> Hi, > >>>>> > >>>>> I'm seeing userspace program getting stuck on aarch64, on kernels 4= .20 > >>>>> and > >>>>> newer. > >>>>> It stalls from seconds to hours. > >>>>> > >>>>> I have simplified it to following scenario (reproducer linked below > >>>>> [1]): > >>>>> while (1): > >>>>> spawn Thread 1: mmap, write, munmap > >>>>> spawn Thread 2: > >>>>> > >>>>> Thread 1 is sporadically getting stuck on write to mapped area. > >>>>> User-space > >>>>> is not > >>>>> moving forward - stdout output stops. Observed CPU usage is however > >>>>> 100%. > >>>>> > >>>>> At this time, kernel appears to be busy handling page faults (~700k= per > >>>>> second): > >>>>> > >>>>> # perf top -a -g > >>>>> - 98.97% 8.30% a.out [.] map_write_unmap > >>>>> - 23.52% map_write_unmap > >>>>> - 24.29% el0_sync > >>>>> - 10.42% do_mem_abort > >>>>> - 17.81% do_translation_fault > >>>>> - 33.01% do_page_fault > >>>>> - 56.18% handle_mm_fault > >>>>> 40.26% __handle_mm_fault > >>>>> 2.19% __ll_sc___cmpxchg_case_acq_4 > >>>>> 0.87% mem_cgroup_from_task > >>>>> - 6.18% find_vma > >>>>> 5.38% vmacache_find > >>>>> 1.35% __ll_sc___cmpxchg_case_acq_8 > >>>>> 1.23% __ll_sc_atomic64_sub_return_release > >>>>> 0.78% down_read_trylock > >>>>> 0.93% do_translation_fault > >>>>> + 8.30% thread_start > >>>>> > >>>>> # perf stat -p 8189 -d > >>>>> ^C > >>>>> Performance counter stats for process id '8189': > >>>>> > >>>>> 984.311350 task-clock (msec) # 1.000 CPU= s > >>>>> utilized > >>>>> 0 context-switches # 0.000 K/s= ec > >>>>> 0 cpu-migrations # 0.000 K/s= ec > >>>>> 723,641 page-faults # 0.735 M/s= ec > >>>>> 2,559,199,434 cycles # 2.600 GHz > >>>>> 711,933,112 instructions # 0.28 ins= n > >>>>> per > >>>>> cycle > >>>>> branches > >>>>> 757,658 branch-misses > >>>>> 205,840,557 L1-dcache-loads # 209.121 M/s= ec > >>>>> 40,561,529 L1-dcache-load-misses # 19.71% of = all > >>>>> L1-dcache hits > >>>>> LLC-loads > >>>>> LLC-load-misses > >>>>> > >>>>> 0.984454892 seconds time elapsed > >>>>> > >>>>> With some extra traces, it appears looping in page fault for same > >>>>> address, > >>>>> over and over: > >>>>> do_page_fault // mm_flags: 0x55 > >>>>> __do_page_fault > >>>>> __handle_mm_fault > >>>>> handle_pte_fault > >>>>> ptep_set_access_flags > >>>>> if (pte_same(pte, entry)) // pte: e8000805060f53, > >>>>> entry: > >>>>> e8000805060f53 > >>>>> > >>>>> I had traces in mmap() and munmap() as well, they don't get hit whe= n > >>>>> reproducer > >>>>> hits the bad state. > >>>>> > >>>>> Notes: > >>>>> - I'm not able to reproduce this on x86. > >>>>> - Attaching GDB or strace immediatelly recovers application from st= all. > >>>>> - It also seems to recover faster when system is busy with other ta= sks. > >>>>> - MAP_SHARED vs. MAP_PRIVATE makes no difference. > >>>>> - Turning off THP makes no difference. > >>>>> - Reproducer [1] usually hits it within ~minute on HW described bel= ow. > >>>>> - Longman mentioned that "When the rwsem becomes reader-owned, it > >>>>> causes > >>>>> all the spinning writers to go to sleep adding wakeup latency = to > >>>>> the time required to finish the critical sections", but this l= ooks > >>>>> like busy loop, so I'm not sure if it's related to rwsem issue= s > >>>>> identified > >>>>> in: > >>>>> https://lore.kernel.org/lkml/20190428212557.13482-2-longman@re= dhat.com/ > >>>> It sounds possible to me. What the optimization done by the commit (= "mm: > >>>> mmap: zap pages with read mmap_sem in munmap") is to downgrade write > >>>> rwsem to read when zapping pages and page table in munmap() after th= e > >>>> vmas have been detached from the rbtree. > >>>> > >>>> So the mmap(), which is writer, in your test may steal the lock and > >>>> execute with the munmap(), which is the reader after the downgrade, = in > >>>> parallel to break the mutual exclusion. > >>>> > >>>> In this case, the parallel mmap() may map to the same area since vma= s > >>>> have been detached by munmap(), then mmap() may create the complete = same > >>>> vmas, and page fault happens on the same vma at the same address. > >>>> > >>>> I'm not sure why gdb or strace could recover this, but they use ptra= ce > >>>> which may acquire mmap_sem to break the parallel inadvertently. > >>>> > >>>> May you please try Waiman's patch to see if it makes any difference? > >>> I don't see any difference in behaviour after applying: > >>> [PATCH-tip v7 01/20] locking/rwsem: Prevent decrement of reader c= ount > >>> before increment > >>> Issue is still easily reproducible for me. > >>> > >>> I'm including output of mem_abort_decode() / show_pte() for sample PT= E, > >>> that > >>> I see in page fault loop. (I went through all bits, but couldn't find > >>> anything invalid about it) > >>> > >>> mem_abort_decode: Mem abort info: > >>> mem_abort_decode: ESR =3D 0x92000047 > >>> mem_abort_decode: Exception class =3D DABT (lower EL), IL =3D 3= 2 bits > >>> mem_abort_decode: SET =3D 0, FnV =3D 0 > >>> mem_abort_decode: EA =3D 0, S1PTW =3D 0 > >>> mem_abort_decode: Data abort info: > >>> mem_abort_decode: ISV =3D 0, ISS =3D 0x00000047 > >>> mem_abort_decode: CM =3D 0, WnR =3D 1 > >>> show_pte: user pgtable: 64k pages, 48-bit VAs, pgdp =3D > >>> 0000000067027567 > >>> show_pte: [0000ffff6dff0000] pgd=3D000000176bae0003 > >>> show_pte: , pud=3D000000176bae0003 > >>> show_pte: , pmd=3D000000174ad60003 > >>> show_pte: , pte=3D00e80008023a0f53 > >>> show_pte: , pte_pfn: 8023a > >>> > >>> >>> print bin(0x47) > >>> 0b1000111 > >>> > >>> Per D12-2779 (ARM Architecture Reference Manual), > >>> ISS encoding for an exception from an Instruction Abort: > >>> IFSC, bits [5:0], Instruction Fault Status Code > >>> 0b000111 Translation fault, level 3 > >>> > >>> --- > >>> > >>> My theory is that TLB is getting broken. > > Theory continued: > > > > unmap_region() is batching updates to TLB (for vmas and page tables). > > And at the same time another thread handles page fault for same mm, > > which increases "tlb_flush_pending". > > > > tlb_finish_mmu() called from unmap_region() will thus set 'force =3D 1'= . > > And arch_tlb_finish_mmu() will in turn reset TLB range, presumably maki= ng > > it smaller then it would be if force =3D=3D 0. > > > > Change below appears to fix it: > > > > diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c > > index f2f03c655807..a4cef21bd62b 100644 > > --- a/mm/mmu_gather.c > > +++ b/mm/mmu_gather.c > > @@ -93,7 +93,7 @@ void arch_tlb_finish_mmu(struct mmu_gather *tlb, > > struct mmu_gather_batch *batch, *next; > > =20 > > if (force) { > > - __tlb_reset_range(tlb); > > __tlb_adjust_range(tlb, start, end - start); >=20 > I don't get why the change could fix it? My guess is that reset clears "tlb->freed_tables", which changes how tlb_flush() operates, see "bool last_level =3D !tlb->freed_tables;" in arch/arm64/include/asm/tlb.h. Maybe that doesn't clear some intermediate entries? No clue. If I let it reset the range, but preserve "freed_tables", it also seems to solve the problem: diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c index f2f03c655807..17fb0d7edc03 100644 --- a/mm/mmu_gather.c +++ b/mm/mmu_gather.c @@ -93,8 +93,20 @@ void arch_tlb_finish_mmu(struct mmu_gather *tlb, struct mmu_gather_batch *batch, *next; =20 if (force) { - __tlb_reset_range(tlb); + if (tlb->fullmm) { + tlb->start =3D tlb->end =3D ~0; + } else { + tlb->start =3D TASK_SIZE; + tlb->end =3D 0; + } __tlb_adjust_range(tlb, start, end - start); > __tlb_reset_range() just reset > start and end to TASK_SIZE and 0, then __tlb_adjust_range() set proper > start and end. I don't get why "force" flush smaller range? I'm still trying to understand this part. It's actually not smaller, but it= changes: unmap_region() # vm_start: ffff49bd0000 vm_end: ffff49be0000 ... # tlb.start, tlb.end: 1000000000000 0 free_pgtables() # tlb.start, tlb.end: ffff40000000 ffff40010000 tlb_finish_mmu() arch_tlb_finish_mmu() # will see force =3D=3D 1 # resets tlb.start, tlb.end to: ffff49bd0000 ffff49be0000 >=20 > > } > > > >>> I made a dummy kernel module that exports debugfs file, which on read > >>> triggers: > >>> flush_tlb_all(); > >>> > >>> Any time reproducer stalls and I read debugfs file, it recovers > >>> immediately and resumes printing to stdout. > >> That commit doesn't change anything about TLB flush, just move zapping > >> pages under read mmap_sem as what MADV_DONTNEED does. > >> > >> I don't have aarch64 board to reproduce and debug it. And, I'm not > >> familiar with aarch64 architecture either. But, some history told me t= he > >> parallel zapping page may run into stale TLB and defer a flush meaning > >> that this call may observe pte_none and fails to flush the TLB. But, > >> this has been solved by commit 56236a59556c ("mm: refactor TLB gatheri= ng > >> API") and 99baac21e458 ("mm: fix MADV_[FREE|DONTNEED] TLB flush miss > >> problem"). > >> > >> For more detail, please refer to commit 4647706ebeee ("mm: always flus= h > >> VMA ranges affected by zap_page_range"). Copied Mel and Rik in this > >> thread. Also added Will Deacon and Catalin Marinas, who are aarch64 > >> maintainers, in this loop > > Thanks > > > >> But, your test (triggering TLB flush) does demonstrate TLB flush is > >> *not* done properly at some point as expected for aarch64. Could you > >> please give the below patch a try? > > Your patch also fixes my reproducer. >=20 > Thanks for testing it. >=20 > > > >> diff --git a/mm/memory.c b/mm/memory.c > >> index ab650c2..ef41ad5 100644 > >> --- a/mm/memory.c > >> +++ b/mm/memory.c > >> @@ -1336,8 +1336,10 @@ void unmap_vmas(struct mmu_gather *tlb, > >> > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mmu_notifier_range_init(&= range, vma->vm_mm, start_addr, > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 end_addr); > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mmu_notifier_invalidate_r= ange_start(&range); > >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for ( ; vma && vma->vm_start < e= nd_addr; vma =3D vma->vm_next) > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for ( ; vma && vma->vm_start < e= nd_addr; vma =3D vma->vm_next) { > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 unmap_single_vma(tlb, vma, start_addr, end_addr, N= ULL); > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 flush_tlb_range(vma, start_addr, end_addr); > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mmu_notifier_invalidate_r= ange_end(&range); > >> =C2=A0} > >> > >>>>> - I tried 2 different aarch64 systems so far: APM X-Gene CPU Potenz= a A3 > >>>>> and > >>>>> Qualcomm 65-LA-115-151. > >>>>> I can reproduce it on both with v5.1-rc7. It's easier to repro= duce > >>>>> on latter one (for longer periods of time), which has 46 CPUs. > >>>>> - Sample output of reproducer on otherwise idle system: > >>>>> # ./a.out > >>>>> [00000314] map_write_unmap took: 26305 ms > >>>>> [00000867] map_write_unmap took: 13642 ms > >>>>> [00002200] map_write_unmap took: 44237 ms > >>>>> [00002851] map_write_unmap took: 992 ms > >>>>> [00004725] map_write_unmap took: 542 ms > >>>>> [00006443] map_write_unmap took: 5333 ms > >>>>> [00006593] map_write_unmap took: 21162 ms > >>>>> [00007435] map_write_unmap took: 16982 ms > >>>>> [00007488] map_write unmap took: 13 ms^C > >>>>> > >>>>> I ran a bisect, which identified following commit as first bad one: > >>>>> dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munma= p") > >>>>> > >>>>> I can also make the issue go away with following change: > >>>>> diff --git a/mm/mmap.c b/mm/mmap.c > >>>>> index 330f12c17fa1..13ce465740e2 100644 > >>>>> --- a/mm/mmap.c > >>>>> +++ b/mm/mmap.c > >>>>> @@ -2844,7 +2844,7 @@ EXPORT_SYMBOL(vm_munmap); > >>>>> SYSCALL_DEFINE2(munmap, unsigned long, addr, size_t, len) > >>>>> { > >>>>> profile_munmap(addr); > >>>>> - return __vm_munmap(addr, len, true); > >>>>> + return __vm_munmap(addr, len, false); > >>>>> } > >>>>> > >>>>> # cat /proc/cpuinfo | head > >>>>> processor : 0 > >>>>> BogoMIPS : 40.00 > >>>>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid > >>>>> asimdrdm > >>>>> CPU implementer : 0x51 > >>>>> CPU architecture: 8 > >>>>> CPU variant : 0x0 > >>>>> CPU part : 0xc00 > >>>>> CPU revision : 1 > >>>>> > >>>>> # numactl -H > >>>>> available: 1 nodes (0) > >>>>> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 2= 1 22 > >>>>> 23 > >>>>> 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 > >>>>> node 0 size: 97938 MB > >>>>> node 0 free: 95732 MB > >>>>> node distances: > >>>>> node 0 > >>>>> 0: 10 > >>>>> > >>>>> Regards, > >>>>> Jan > >>>>> > >>>>> [1] > >>>>> https://github.com/jstancek/reproducers/blob/master/kernel/page_fau= lt_stall/mmap5.c > >>>>> [2] > >>>>> https://github.com/jstancek/reproducers/blob/master/kernel/page_fau= lt_stall/config > >> >=20 >=20