From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f198.google.com (mail-wr0-f198.google.com [209.85.128.198]) by kanga.kvack.org (Postfix) with ESMTP id 326FF6B0003 for ; Wed, 21 Feb 2018 02:36:49 -0500 (EST) Received: by mail-wr0-f198.google.com with SMTP id w10so652160wrg.2 for ; Tue, 20 Feb 2018 23:36:49 -0800 (PST) Received: from huawei.com (szxga03-in.huawei.com. [45.249.212.189]) by mx.google.com with ESMTPS id u6si681185edj.291.2018.02.20.23.36.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Feb 2018 23:36:47 -0800 (PST) From: "Wangxuefeng (E)" Subject: =?gb2312?B?tPC4tDogW1JGQyBwYXRjaF0gaW9yZW1hcDogZG9uJ3Qgc2V0IHVwIGh1Z2Ug?= =?gb2312?Q?I/O_mappings_when_p4d/pud/pmd_is_zero?= Date: Wed, 21 Feb 2018 07:36:34 +0000 Message-ID: References: <1514460261-65222-1-git-send-email-guohanjun@huawei.com> <861128ce-966f-7006-45ba-6a7298918686@codeaurora.org>,<1519175992.16384.121.camel@hpe.com> In-Reply-To: <1519175992.16384.121.camel@hpe.com> Content-Language: zh-CN Content-Type: multipart/alternative; boundary="_000_etPan5a8d21801dbfd27249b8localhost_" MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: "toshi.kani" , linux-arm-kernel , cpandya , linux-kernel , "Guohanjun (Hanjun Guo)" Cc: Linuxarm , linux-mm , akpm , "mark.rutland" , "will.deacon" , "catalin.marinas" , mhocko , "hanjun.guo" --_000_etPan5a8d21801dbfd27249b8localhost_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGmjrFRvc2hpDQogICAgIFRoZSBvbGQgZmxvdyBvZiByZXVzZSB0aGUgNGsgcGFnZSBhcyAyTSBw YWdlIGRvZXMgbm90IGZvbGxvdyB0aGUgQkJNIGZsb3cgZm9yIHBhZ2UgdGFibGUgcmVjb25zdHJ1 Y3Rpb26jrG5vdCBvbmx5IHRoZSBtZW1vcnkgbGVhayBwcm9ibGVtcy4gIElmIEJCTSBmbG93IGlz IG5vdCBmb2xsb3dlZKOsdGhlIHNwZWN1bGF0aXZlIHByZWZldGNoIG9mIHRsYiB3aWxsIG1hZGUg ZmFsc2UgdGxiIGVudHJpZXMgY2FjaGVkIGluIE1NVSwgdGhlIGZhbHNlIGFkZHJlc3Mgd2lsbCBi ZSBnb3SjrCBwYW5pYyB3aWxsIGhhcHBlbi4NCg0KVEhBTktTDQogICAgICAgIHdhbmcgIHh1ZWZl bmcNCg0KU2VudCBmcm9tIEhVQVdFSSBBbnlPZmZpY2UNCreivP7Iy6O6S2FuaSwgVG9zaGkNCsrV vP7Iy6O6bGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnLGNwYW5keWFAY29kZWF1 cm9yYS5vcmcsbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZyy5+bquvvwNCrOty82jukxpbnV4 YXJtLGxpbnV4LW1tQGt2YWNrLm9yZyzN9dGpt+UsYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZyxt YXJrLnJ1dGxhbmRAYXJtLmNvbSx3aWxsLmRlYWNvbkBhcm0uY29tLGNhdGFsaW4ubWFyaW5hc0Bh cm0uY29tLEhvY2tvLCBNaWNoYWwsaGFuanVuLmd1b0BsaW5hcm8ub3JnDQrKsbzko7oyMDE4LTAy LTIxIDA4OjM0OjQ5DQrW98ziOlJlOiBbUkZDIHBhdGNoXSBpb3JlbWFwOiBkb24ndCBzZXQgdXAg aHVnZSBJL08gbWFwcGluZ3Mgd2hlbiBwNGQvcHVkL3BtZCBpcyB6ZXJvDQoNCk9uIFR1ZSwgMjAx OC0wMi0yMCBhdCAxNDo1NCArMDUzMCwgQ2hpbnRhbiBQYW5keWEgd3JvdGU6DQo+DQo+IE9uIDEy LzI4LzIwMTcgNDo1NCBQTSwgSGFuanVuIEd1byB3cm90ZToNCj4gPiBGcm9tOiBIYW5qdW4gR3Vv IDxoYW5qdW4uZ3VvQGxpbmFyby5vcmc+DQo+ID4NCj4gPiBXaGVuIHdlIHVzaW5nIGlvdW5tYXAo KSB0byBmcmVlIHRoZSA0SyBtYXBwaW5nLCBpdCBqdXN0IGNsZWFyIHRoZSBQVEVzDQo+ID4gYnV0 IGxlYXZlIFA0RC9QVUQvUE1EIHVuY2hhbmdlZCwgYWxzbyB3aWxsIG5vdCBmcmVlIHRoZSBtZW1v cnkgb2YgcGFnZQ0KPiA+IHRhYmxlcy4NCj4gPg0KPiA+IFRoaXMgd2lsbCBjYXVzZSBpc3N1ZXMg b24gQVJNNjQgcGxhdGZvcm0gKG5vdCBzdXJlIGlmIG90aGVyIGFyY2hzIGhhdmUNCj4gPiB0aGUg c2FtZSBpc3N1ZSkgZm9yIHRoaXMgY2FzZToNCj4gPg0KPiA+IDEuIGlvcmVtYXAgYSA0SyBzaXpl LCB2YWxpZCBwYWdlIHRhYmxlIHdpbGwgYnVpbGQsDQo+ID4gMi4gaW91bm1hcCBpdCwgcHRlMCB3 aWxsIHNldCB0byAwOw0KPiA+IDMuIGlvcmVtYXAgdGhlIHNhbWUgYWRkcmVzcyB3aXRoIDJNIHNp emUsIHBnZC9wbWQgaXMgdW5jaGFuZ2VkLA0KPiA+ICAgICB0aGVuIHNldCB0aGUgYSBuZXcgdmFs dWUgZm9yIHBtZDsNCj4gPiA0LiBwdGUwIGlzIGxlYWtlZDsNCj4gPiA1LiBDUFUgbWF5IG1lZXQg ZXhjZXB0aW9uIGJlY2F1c2UgdGhlIG9sZCBwbWQgaXMgc3RpbGwgaW4gVExCLA0KPiA+ICAgICB3 aGljaCB3aWxsIGxlYWQgdG8ga2VybmVsIHBhbmljLg0KPiA+DQo+ID4gRml4IGl0IGJ5IHNraXAg c2V0dGluZyB1cCB0aGUgaHVnZSBJL08gbWFwcGluZ3Mgd2hlbiBwNGQvcHVkL3BtZCBpcw0KPiA+ IHplcm8uDQo+ID4NCj4NCj4gT25lIG9idmlvdXMgcHJvYmxlbSBJIHNlZSBoZXJlIGlzLCBvbmNl IGFueSAybmQgbGV2ZWwgZW50cnkgaGFzIDNyZA0KPiBsZXZlbCBtYXBwaW5nLCB0aGlzIGVudHJ5 IGNhbid0IG1hcCAyTSBzZWN0aW9uIGV2ZXIgaW4gZnV0dXJlLiBUaGlzIHdheSwNCj4gd2Ugd2ls bCBmcmFnbWVudCBlbnRpcmUgdmlydHVhbCBzcGFjZSBvdmVyIHRpbWUuDQo+DQo+IFRoZSBjb2Rl IHlvdSBhcmUgY2hhbmdpbmcgaXMgY29tbW9uIGJldHdlZW4gMzItYml0IHN5c3RlbXMgYXMgd2Vs bCAoSQ0KPiB0aGluaykuIEFuZCBydW5uaW5nIG91dCBvZiBzZWN0aW9uIG1hcHBpbmcgd291bGQg YmUgYSByZWFsaXR5IGluDQo+IHByYWN0aWNhbCB0ZXJtcy4NCj4NCj4gU28sIGlmIHdlIGNhbiBk byB0aGUgZm9sbG93aW5nIGFzIGEgZml4IHVwLCB3ZSB3b3VsZCBiZSBzYXZlZC4NCj4gMSkgSW52 YWxpZGF0ZSAybmQgbGV2ZWwgZW50cnkgZnJvbSBUTEIsIGFuZA0KPiAyKSBGcmVlIHRoZSBwYWdl IHdoaWNoIGhvbGRzIGxhc3QgbGV2ZWwgcGFnZSB0YWJsZQ0KPg0KPiBCVFcsIGlzIHRoZXJlIGFu eSBmdXJ0aGVyIGRpc2N1c3Npb24gZ29pbmcgb24gdGhpcyB0b3BpYyB3aGljaCBJIGFtDQo+IG1p c3NpbmcgPw0KDQpZZXMsIEkgc3VnZ2VzdGVkIHRvIGZyZWUgdXAgYSBwdGUgdGFibGUgaW4gbXkg bGFzdCByZXBseS4NCmh0dHBzOi8vcGF0Y2h3b3JrLmtlcm5lbC5vcmcvcGF0Y2gvMTAxMzQ1ODEv DQoNClRoYW5rcywNCi1Ub3NoaQ0K --_000_etPan5a8d21801dbfd27249b8localhost_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
hi=A3=ACToshi
     The old flow of reuse the 4k page as 2M page does = not follow the BBM flow for page table reconstruction=A3=ACnot only the mem= ory leak problems.  If BBM flow is not followed=A3=ACthe speculative p= refetch of tlb will made false tlb entries cached in MMU, the false address will be got=A3=AC panic will happen.

THANKS
        wang  xuefeng

Sent from HUAWEI AnyOffice
=B7=A2=BC=FE=C8=CB=A3=BAKani, To= shi
=CA=D5=BC=FE=C8=CB=A3=BAlinux-ar= m-kernel@lists.infradead.org,cpandya@codeaurora.org,linux-kernel@vger.kerne= l.org,=B9=F9=BA=AE=BE=FC
=B3=AD=CB=CD=A3=BALinuxarm,linux= -mm@kvack.org,=CD=F5=D1=A9=B7=E5,akpm@linux-foundation.org,mark.rutland@arm= .com,will.deacon@arm.com,catalin.marinas@arm.com,Hocko, Michal,hanjun.guo@l= inaro.org
=CA=B1=BC=E4=A3=BA2018-02-21 08:= 34:49
=D6=F7=CC=E2:Re: [RFC patch] ior= emap: don't set up huge I/O mappings when p4d/pud/pmd is zero

On Tue, 2018-02-20 at 14:54 +0530, Chintan Pan= dya wrote:
>
> On 12/28/2017 4:54 PM, Hanjun Guo wrote:
> > From: Hanjun Guo <hanjun.guo@linaro.org>
> >
> > When we using iounmap() to free the 4K mapping, it just clear the= PTEs
> > but leave P4D/PUD/PMD unchanged, also will not free the memory of= page
> > tables.
> >
> > This will cause issues on ARM64 platform (not sure if other archs= have
> > the same issue) for this case:
> >
> > 1. ioremap a 4K size, valid page table will build,
> > 2. iounmap it, pte0 will set to 0;
> > 3. ioremap the same address with 2M size, pgd/pmd is unchanged, > >     then set the a new value for pmd;
> > 4. pte0 is leaked;
> > 5. CPU may meet exception because the old pmd is still in TLB, > >     which will lead to kernel panic.
> >
> > Fix it by skip setting up the huge I/O mappings when p4d/pud/pmd = is
> > zero.
> >
>
> One obvious problem I see here is, once any 2nd level entry has 3rd > level mapping, this entry can't map 2M section ever in future. This wa= y,
> we will fragment entire virtual space over time.
>
> The code you are changing is common between 32-bit systems as well (I =
> think). And running out of section mapping would be a reality in
> practical terms.
>
> So, if we can do the following as a fix up, we would be saved.
> 1) Invalidate 2nd level entry from TLB, and
> 2) Free the page which holds last level page table
>
> BTW, is there any further discussion going on this topic which I am > missing ?

Yes, I suggested to free up a pte table in my last reply.
https://patchwork.= kernel.org/patch/10134581/

Thanks,
-Toshi
 --_000_etPan5a8d21801dbfd27249b8localhost_-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org