From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerome Glisse Subject: Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma Date: Wed, 30 Jan 2019 17:58:50 -0500 Message-ID: <20190130225849.GJ5061@redhat.com> References: <20190130201114.GB17915@mellanox.com> <20190130204332.GF5061@redhat.com> <20190130204954.GI17080@mellanox.com> <20190130214525.GG5061@redhat.com> <20190130215600.GM17080@mellanox.com> <20190130223027.GH5061@redhat.com> <20190130223258.GB25486@mellanox.com> <20190130224705.GI5061@redhat.com> <20190130225148.GC25486@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20190130225148.GC25486@mellanox.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jason Gunthorpe Cc: Joerg Roedel , "Rafael J . Wysocki" , Greg Kroah-Hartman , Felix Kuehling , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Christoph Hellwig , "linux-mm@kvack.org" , "iommu@lists.linux-foundation.org" , "linux-pci@vger.kernel.org" , Bjorn Helgaas , Robin Murphy , Logan Gunthorpe , Christian Koenig , Marek Szyprowski List-Id: iommu@lists.linux-foundation.org T24gV2VkLCBKYW4gMzAsIDIwMTkgYXQgMTA6NTE6NTVQTSArMDAwMCwgSmFzb24gR3VudGhvcnBl IHdyb3RlOgo+IE9uIFdlZCwgSmFuIDMwLCAyMDE5IGF0IDA1OjQ3OjA1UE0gLTA1MDAsIEplcm9t ZSBHbGlzc2Ugd3JvdGU6Cj4gPiBPbiBXZWQsIEphbiAzMCwgMjAxOSBhdCAxMDozMzowNFBNICsw MDAwLCBKYXNvbiBHdW50aG9ycGUgd3JvdGU6Cj4gPiA+IE9uIFdlZCwgSmFuIDMwLCAyMDE5IGF0 IDA1OjMwOjI3UE0gLTA1MDAsIEplcm9tZSBHbGlzc2Ugd3JvdGU6Cj4gPiA+IAo+ID4gPiA+ID4g V2hhdCBpcyB0aGUgcHJvYmxlbSBpbiB0aGUgSE1NIG1pcnJvciB0aGF0IGl0IG5lZWRzIHRoaXMg cmVzdHJpY3Rpb24/Cj4gPiA+ID4gCj4gPiA+ID4gTm8gcmVzdHJpY3Rpb24gYXQgYWxsIGhlcmUu IEkgdGhpbmsgaSBqdXN0IHdhc24ndCB1bmRlcnN0b29kLgo+ID4gPiAKPiA+ID4gQXJlIHlvdSBh cmUgdGFsa2luZyBhYm91dCBmcm9tIHRoZSBleHBvcnRpbmcgc2lkZSAtIHdoZXJlIHRoZSB0aGlu Zwo+ID4gPiBjcmVhdGluZyB0aGUgVk1BIGNhbiByZWFsbHkgb25seSBwdXQgb25lIGRpc3RpbmN0 IG9iamVjdCBpbnRvIGl0Pwo+ID4gCj4gPiBUaGUgbWVzc2FnZSBpIHdhcyB0cnlpbmcgdG8gZ2V0 IGFjY3Jvc3MgaXMgdGhhdCBITU0gbWlycm9yIHdpbGwKPiA+IGFsd2F5cyBzdWNjZWVkIGZvciBl dmVyeXRoaW5nKiBleGNlcHQgZm9yIHNwZWNpYWwgdm1hIGllIG1tYXAgb2YKPiA+IGRldmljZSBm aWxlLiBGb3IgdGhvc2UgaXQgY2FuIG9ubHkgc3VjY2VlZCBpZiBhIHAycF9tYXAoKSBjYWxsCj4g PiBzdWNjZWVkLgo+ID4gCj4gPiBTbyBhbnkgdXNlciBvZiBITU0gbWlycm9yIG1pZ2h0IHRvIGtu b3cgd2h5IHRoZSBtaXJyb3JpbmcgZmFpbCBpZQo+ID4gd2FzIGl0IGJlY2F1c2Ugc29tZXRoaW5n IGV4Y2VwdGlvbmFsIGlzIGhhcHBlbmluZyA/IE9yIGlzIGl0IGJlY2F1c2UKPiA+IGkgd2FzIHRy eWluZyB0byBtYXAgYSBzcGVjaWFsIHZtYSB3aGljaCBjYW4gYmUgZm9yYmlkZW4uCj4gPiAKPiA+ IEhlbmNlIHdoeSBpIGFzc3VtZSB0aGF0IHlvdSBtaWdodCB3YW50IHRvIGtub3cgYWJvdXQgc3Vj aCBwMnBfbWFwCj4gPiBmYWlsdXJlIGF0IHRoZSB0aW1lIHlvdSBjcmVhdGUgdGhlIHVtZW0gb2Rw IG9iamVjdCBhcyBpdCBtaWdodCBiZQo+ID4gc29tZSBmYWlsdXJlIHlvdSBtaWdodCB3YW50IHRv IHJlcG9ydCBkaWZmZXJlbnRseSBhbmQgaGFuZGxlCj4gPiBkaWZmZXJlbnRseS4gSWYgeW91IGRv IG5vdCBjYXJlIGFib3V0IGRpZmZlcmVudGlhdGluZyBPT00gb3IKPiA+IGV4Y2VwdGlvbmFsIGZh aWx1cmUgZnJvbSBwMnBfbWFwIGZhaWx1cmUgdGhhbiB5b3UgaGF2ZSBub3RoaW5nIHRvCj4gPiB3 b3JyeSBhYm91dCB5b3Ugd2lsbCBnZXQgdGhlIHNhbWUgZXJyb3IgZnJvbSBITU0gZm9yIGJvdGgu Cj4gCj4gSSB0aGluayBteSBob3BlIGhlcmUgd2FzIHRoYXQgd2UgY291bGQgaGF2ZSBzb21lIGtp bmQgb2YgJ3RyaWFsJwo+IGludGVyZmFjZSB3aGVyZSB2ZXJ5IGVhcnkgdXNlcnMgY2FuIGNhbGwK PiAnaG1tX21pcnJvcl9pc19tYXliZV9zdXBwb3J0ZWQoZGV2LCB1c2VyX3B0ciwgbGVuKScgYW5k IGdldCBhIGZhaWx1cmUKPiBpbmRpY2F0aW9uLgo+IAo+IFdlIHByb2JhYmx5IHdvdWxkbid0IGNh bGwgdGhpcyBvbiB0aGUgZnVsbCBhZGRyZXNzIHNwYWNlIHRob3VnaAoKWWVzIHdlIGNhbiBkbyBz cGVjaWFsIHdyYXBwZXIgYXJvdW5kIHRoZSBnZW5lcmFsIGNhc2UgdGhhdCBhbGxvdwpjYWxsZXIg dG8gZGlmZmVyZW50aWF0ZSBmYWlsdXJlLiBTbyBhdCBjcmVhdGlvbiB5b3UgY2FsbCB0aGUKc3Bl Y2lhbCBmbGF2b3IgYW5kIGdldCBwcm9wZXIgZGlzdGluY3Rpb24gYmV0d2VlbiBlcnJvci4gQWZ0 ZXJ3YXJkCmR1cmluZyBub3JtYWwgb3BlcmF0aW9uIGFueSBmYWlsdXJlIGlzIGp1c3QgdHJlYXRl ZCBpbiBhIHNhbWUgd2F5Cm5vIG1hdHRlciB3aGF0IGlzIHRoZSByZWFzb25zIChtdW5tYXAsIG1y ZW1hcCwgbXByb3RlY3QsIC4uLikuCgoKPiBCZXlvbmQgdGhhdCBpdCBpcyBqdXN0IGluZXZpdGFi bGUgdGhlcmUgY2FuIGJlIHByb2JsZW1zIGZhdWx0aW5nIGlmCj4gdGhlIG1lbW9yeSBtYXAgaXMg bWVzc2VkIHdpdGggYWZ0ZXIgTVIgaXMgY3JlYXRlZC4KPiAKPiBBbmQgaGVyZSBhZ2FpbiwgSSBk b24ndCB3YW50IHRvIHdvcnJ5IGFib3V0IGFueSBwYXJ0aWN1bGFyIFZNQQo+IGJvdW5kYXJpZXMu LgoKWW91IGRvIG5vdCBoYXZlIHRvIHdvcnJ5IGFib3V0IGJvdW5kYXJpZXMgSE1NIHdpbGwgcmV0 dXJuIC1FRkFVTFQKaWYgdGhlcmUgaXMgbm8gdmFsaWQgdm1hIGJlaGluZCB0aGUgYWRkcmVzcyB5 b3UgYXJlIHRyeWluZyB0byBtYXAKKG9yIGlmIHRoZSB2bWEgcHJvdCBkb2VzIG5vdCBhbGxvdyB5 b3UgdG8gYWNjZXNzIGl0KS4gU28gdGhlbiB5b3UKY2FuIGhhbmRsZSB0aGF0IGZhaWx1cmUganVz dCBsaWtlIHlvdSBkbyBub3cgYW5kIGFzIG15IE9EUCBITU0KcGF0Y2ggcHJlc2VydmUuCgpDaGVl cnMsCkrDqXLDtG1lCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9y ZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZl bAo= 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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 BBA01C282D8 for ; Wed, 30 Jan 2019 22:59:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6C84E20857 for ; Wed, 30 Jan 2019 22:59:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725786AbfA3W66 (ORCPT ); Wed, 30 Jan 2019 17:58:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53104 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729486AbfA3W64 (ORCPT ); Wed, 30 Jan 2019 17:58:56 -0500 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 80C3086671; Wed, 30 Jan 2019 22:58:55 +0000 (UTC) Received: from redhat.com (ovpn-126-0.rdu2.redhat.com [10.10.126.0]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EACAF608E5; Wed, 30 Jan 2019 22:58:51 +0000 (UTC) Date: Wed, 30 Jan 2019 17:58:50 -0500 From: Jerome Glisse To: Jason Gunthorpe Cc: Logan Gunthorpe , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , "Rafael J . Wysocki" , Bjorn Helgaas , Christian Koenig , Felix Kuehling , "linux-pci@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Christoph Hellwig , Marek Szyprowski , Robin Murphy , Joerg Roedel , "iommu@lists.linux-foundation.org" Subject: Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma Message-ID: <20190130225849.GJ5061@redhat.com> References: <20190130201114.GB17915@mellanox.com> <20190130204332.GF5061@redhat.com> <20190130204954.GI17080@mellanox.com> <20190130214525.GG5061@redhat.com> <20190130215600.GM17080@mellanox.com> <20190130223027.GH5061@redhat.com> <20190130223258.GB25486@mellanox.com> <20190130224705.GI5061@redhat.com> <20190130225148.GC25486@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190130225148.GC25486@mellanox.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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.26]); Wed, 30 Jan 2019 22:58:55 +0000 (UTC) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Wed, Jan 30, 2019 at 10:51:55PM +0000, Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 05:47:05PM -0500, Jerome Glisse wrote: > > On Wed, Jan 30, 2019 at 10:33:04PM +0000, Jason Gunthorpe wrote: > > > On Wed, Jan 30, 2019 at 05:30:27PM -0500, Jerome Glisse wrote: > > > > > > > > What is the problem in the HMM mirror that it needs this restriction? > > > > > > > > No restriction at all here. I think i just wasn't understood. > > > > > > Are you are talking about from the exporting side - where the thing > > > creating the VMA can really only put one distinct object into it? > > > > The message i was trying to get accross is that HMM mirror will > > always succeed for everything* except for special vma ie mmap of > > device file. For those it can only succeed if a p2p_map() call > > succeed. > > > > So any user of HMM mirror might to know why the mirroring fail ie > > was it because something exceptional is happening ? Or is it because > > i was trying to map a special vma which can be forbiden. > > > > Hence why i assume that you might want to know about such p2p_map > > failure at the time you create the umem odp object as it might be > > some failure you might want to report differently and handle > > differently. If you do not care about differentiating OOM or > > exceptional failure from p2p_map failure than you have nothing to > > worry about you will get the same error from HMM for both. > > I think my hope here was that we could have some kind of 'trial' > interface where very eary users can call > 'hmm_mirror_is_maybe_supported(dev, user_ptr, len)' and get a failure > indication. > > We probably wouldn't call this on the full address space though Yes we can do special wrapper around the general case that allow caller to differentiate failure. So at creation you call the special flavor and get proper distinction between error. Afterward during normal operation any failure is just treated in a same way no matter what is the reasons (munmap, mremap, mprotect, ...). > Beyond that it is just inevitable there can be problems faulting if > the memory map is messed with after MR is created. > > And here again, I don't want to worry about any particular VMA > boundaries.. You do not have to worry about boundaries HMM will return -EFAULT if there is no valid vma behind the address you are trying to map (or if the vma prot does not allow you to access it). So then you can handle that failure just like you do now and as my ODP HMM patch preserve. Cheers, Jérôme