From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerome Glisse Subject: Re: DANGER WILL ROBINSON, DANGER Date: Thu, 15 Aug 2019 15:19:29 -0400 Message-ID: <20190815191929.GA9253@redhat.com> References: <20190809160047.8319-1-alazar@bitdefender.com> <20190809160047.8319-72-alazar@bitdefender.com> <20190809162444.GP5482@bombadil.infradead.org> <1565694095.D172a51.28640.@15f23d3a749365d981e968181cce585d2dcb3ffa> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <1565694095.D172a51.28640.@15f23d3a749365d981e968181cce585d2dcb3ffa> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Adalbert =?utf-8?B?TGF6xINy?= Cc: Tamas K Lengyel , Weijiang Yang , Yu C , kvm@vger.kernel.org, Radim =?utf-8?B?S3LEjW3DocWZ?= , Jan Kiszka , Samuel =?iso-8859-1?Q?Laur=E9n?= , Konrad Rzeszutek Wilk , Matthew Wilcox , virtualization@lists.linux-foundation.org, linux-mm@kvack.org, Patrick Colp , Mathieu Tarral , Stefan Hajnoczi , Mircea =?iso-8859-1?Q?C=EErjaliu?= , Paolo Bonzini , Mihai =?utf-8?B?RG9uyJt1?= List-Id: virtualization@lists.linuxfoundation.org T24gVHVlLCBBdWcgMTMsIDIwMTkgYXQgMDI6MDE6MzVQTSArMDMwMCwgQWRhbGJlcnQgTGF6xINy IHdyb3RlOgo+IE9uIEZyaSwgOSBBdWcgMjAxOSAwOToyNDo0NCAtMDcwMCwgTWF0dGhldyBXaWxj b3ggPHdpbGx5QGluZnJhZGVhZC5vcmc+IHdyb3RlOgo+ID4gT24gRnJpLCBBdWcgMDksIDIwMTkg YXQgMDc6MDA6MjZQTSArMDMwMCwgQWRhbGJlcnQgTGF6xINyIHdyb3RlOgo+ID4gPiArKysgYi9p bmNsdWRlL2xpbnV4L3BhZ2UtZmxhZ3MuaAo+ID4gPiBAQCAtNDE3LDggKzQxNywxMCBAQCBQQUdF RkxBRyhJZGxlLCBpZGxlLCBQRl9BTlkpCj4gPiA+ICAgKi8KPiA+ID4gICNkZWZpbmUgUEFHRV9N QVBQSU5HX0FOT04JMHgxCj4gPiA+ICAjZGVmaW5lIFBBR0VfTUFQUElOR19NT1ZBQkxFCTB4Mgo+ ID4gPiArI2RlZmluZSBQQUdFX01BUFBJTkdfUkVNT1RFCTB4NAo+ID4gCj4gPiBVaC4gIEhvdyBk byB5b3Uga25vdyBwYWdlLT5tYXBwaW5nIHdvdWxkIG90aGVyd2lzZSBoYXZlIGJpdCAyIGNsZWFy Pwo+ID4gV2hvJ3MgZ3VhcmFudGVlaW5nIHRoYXQ/Cj4gPiAKPiA+IFRoaXMgaXMgYW4gYXdmdWxs eSBiaWcgcGF0Y2ggdG8gdGhlIG1lbW9yeSBtYW5hZ2VtZW50IGNvZGUsIGJ1cmllZCBpbgo+ID4g dGhlIG1pZGRsZSBvZiBhIGdpZ2FudGljIHNlcmllcyB3aGljaCBhbG1vc3QgZ3VhcmFudGVlcyBu b2JvZHkgd291bGQKPiA+IGxvb2sgYXQgaXQuICBJIGNhbGwgc2hlbmFuaWdhbnMuCj4gPiAKPiA+ ID4gQEAgLTEwMjEsNyArMTAyMiw3IEBAIHZvaWQgcGFnZV9tb3ZlX2Fub25fcm1hcChzdHJ1Y3Qg cGFnZSAqcGFnZSwgc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEpCj4gPiA+ICAgKiBfX3BhZ2Vf c2V0X2Fub25fcm1hcCAtIHNldCB1cCBuZXcgYW5vbnltb3VzIHJtYXAKPiA+ID4gICAqIEBwYWdl OglQYWdlIG9yIEh1Z2VwYWdlIHRvIGFkZCB0byBybWFwCj4gPiA+ICAgKiBAdm1hOglWTSBhcmVh IHRvIGFkZCBwYWdlIHRvLgo+ID4gPiAtICogQGFkZHJlc3M6CVVzZXIgdmlydHVhbCBhZGRyZXNz IG9mIHRoZSBtYXBwaW5nCQo+ID4gPiArICogQGFkZHJlc3M6CVVzZXIgdmlydHVhbCBhZGRyZXNz IG9mIHRoZSBtYXBwaW5nCj4gPiAKPiA+IEFuZCBtaXhpbmcgaW4gZmx1ZmYgY2hhbmdlcyBsaWtl IHRoaXMgaXMgYSByZWFsIG5vLW5vLiAgVHJ5IGFnYWluLgo+ID4gCj4gCj4gTm8gYmFkIGludGVu dGlvbnMsIGp1c3Qgb3ZlcnplYWxvdXMuCj4gSSBkaWRuJ3Qgd2FudCB0byBoaWRlIGFueXRoaW5n IGZyb20gb3VyIHBhdGNoZXMuCj4gT25jZSB3ZSBhZHZhbmNlIHdpdGggdGhlIGludHJvc3BlY3Rp b24gcGF0Y2hlcyByZWxhdGVkIHRvIEtWTSB3ZSdsbCBiZQo+IGJhY2sgd2l0aCB0aGUgcmVtb3Rl IG1hcHBpbmcgcGF0Y2gsIHNwbGl0IGFuZCBjbGVhbmVkLgoKVGhleSBhcmUgbm90IGJpdCBsZWZ0 IGluIHN0cnVjdCBwYWdlICEgTG9va2luZyBhdCB0aGUgcGF0Y2ggaXQgc2VlbXMKeW91IHdhbnQg dG8gaGF2ZSB5b3VyIG93biBwaW4gY291bnQganVzdCBmb3IgS1ZNLiBUaGlzIGlzIGJhZCwgd2Ug YXJlCmFscmVhZHkgdHJ5aW5nIHRvIHNvbHZlIHRoZSBHVVAgdGhpbmcgKHNlZSBhbGwgdmFyaW91 cyBwYXRjaHNldCBhYm91dApHVVAgcG9zdGVkIHJlY2VudGx5KS4KCllvdSBuZWVkIHRvIHJldGhp bmsgaG93IHlvdSB3YW50IHRvIGFjaGlldmUgdGhpcy4gV2h5IG5vdCBzaW1wbHkgYQpyZW1vdGUg cmVhZCgpL3dyaXRlKCkgaW50byB0aGUgcHJvY2VzcyBtZW1vcnkgaWUgS1ZNSSB3b3VsZCBjYWxs CmFuIGlvY3RsIHRoYXQgYWxsb3cgdG8gcmVhZCBvciB3cml0ZSBpbnRvIGEgcmVtb3RlIHByb2Nl c3MgbWVtb3J5Cmxpa2UgcHRyYWNlKCkgYnV0IG9uIHN0ZXJvaWQgLi4uCgpBZGRpbmcgdGhpcyB3 aG9sZSBiaWcgY29tcGxleCBpbmZyYXN0cnVjdHVyZSB3aXRob3V0IGp1c3RpZmljYXRpb24Kb2Yg d2h5IHdlIG5lZWQgdG8gYXZvaWQgcm91bmQgdHJpcCBpcyBqdXN0IHRvbyBtdWNoIHJlYWxseS4K CkNoZWVycywKSsOpcsO0bWUKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KVmlydHVhbGl6YXRpb24gbWFpbGluZyBsaXN0ClZpcnR1YWxpemF0aW9uQGxpc3Rz LmxpbnV4LWZvdW5kYXRpb24ub3JnCmh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0aW9uLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3ZpcnR1YWxpemF0aW9u 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=-1.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,SUBJ_ALL_CAPS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no 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 AC155C3A589 for ; Thu, 15 Aug 2019 19:19:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 84A6020656 for ; Thu, 15 Aug 2019 19:19:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731745AbfHOTTf (ORCPT ); Thu, 15 Aug 2019 15:19:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44440 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731405AbfHOTTf (ORCPT ); Thu, 15 Aug 2019 15:19:35 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1DE043090FD8; Thu, 15 Aug 2019 19:19:35 +0000 (UTC) Received: from redhat.com (unknown [10.20.6.178]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 29BE219C6A; Thu, 15 Aug 2019 19:19:31 +0000 (UTC) Date: Thu, 15 Aug 2019 15:19:29 -0400 From: Jerome Glisse To: Adalbert =?utf-8?B?TGF6xINy?= Cc: Matthew Wilcox , kvm@vger.kernel.org, linux-mm@kvack.org, virtualization@lists.linux-foundation.org, Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Konrad Rzeszutek Wilk , Tamas K Lengyel , Mathieu Tarral , Samuel =?iso-8859-1?Q?Laur=E9n?= , Patrick Colp , Jan Kiszka , Stefan Hajnoczi , Weijiang Yang , Yu C , Mihai =?utf-8?B?RG9uyJt1?= , Mircea =?iso-8859-1?Q?C=EErjaliu?= Subject: Re: DANGER WILL ROBINSON, DANGER Message-ID: <20190815191929.GA9253@redhat.com> References: <20190809160047.8319-1-alazar@bitdefender.com> <20190809160047.8319-72-alazar@bitdefender.com> <20190809162444.GP5482@bombadil.infradead.org> <1565694095.D172a51.28640.@15f23d3a749365d981e968181cce585d2dcb3ffa> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1565694095.D172a51.28640.@15f23d3a749365d981e968181cce585d2dcb3ffa> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Thu, 15 Aug 2019 19:19:35 +0000 (UTC) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, Aug 13, 2019 at 02:01:35PM +0300, Adalbert Lazăr wrote: > On Fri, 9 Aug 2019 09:24:44 -0700, Matthew Wilcox wrote: > > On Fri, Aug 09, 2019 at 07:00:26PM +0300, Adalbert Lazăr wrote: > > > +++ b/include/linux/page-flags.h > > > @@ -417,8 +417,10 @@ PAGEFLAG(Idle, idle, PF_ANY) > > > */ > > > #define PAGE_MAPPING_ANON 0x1 > > > #define PAGE_MAPPING_MOVABLE 0x2 > > > +#define PAGE_MAPPING_REMOTE 0x4 > > > > Uh. How do you know page->mapping would otherwise have bit 2 clear? > > Who's guaranteeing that? > > > > This is an awfully big patch to the memory management code, buried in > > the middle of a gigantic series which almost guarantees nobody would > > look at it. I call shenanigans. > > > > > @@ -1021,7 +1022,7 @@ void page_move_anon_rmap(struct page *page, struct vm_area_struct *vma) > > > * __page_set_anon_rmap - set up new anonymous rmap > > > * @page: Page or Hugepage to add to rmap > > > * @vma: VM area to add page to. > > > - * @address: User virtual address of the mapping > > > + * @address: User virtual address of the mapping > > > > And mixing in fluff changes like this is a real no-no. Try again. > > > > No bad intentions, just overzealous. > I didn't want to hide anything from our patches. > Once we advance with the introspection patches related to KVM we'll be > back with the remote mapping patch, split and cleaned. They are not bit left in struct page ! Looking at the patch it seems you want to have your own pin count just for KVM. This is bad, we are already trying to solve the GUP thing (see all various patchset about GUP posted recently). You need to rethink how you want to achieve this. Why not simply a remote read()/write() into the process memory ie KVMI would call an ioctl that allow to read or write into a remote process memory like ptrace() but on steroid ... Adding this whole big complex infrastructure without justification of why we need to avoid round trip is just too much really. Cheers, Jérôme