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=-4.9 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,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 BA85DC43461 for ; Wed, 16 Sep 2020 15:31:37 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 486D522288 for ; Wed, 16 Sep 2020 15:31:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NonqZq3r" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 486D522288 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 80D406EA3B; Wed, 16 Sep 2020 15:31:36 +0000 (UTC) Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1B5F26EA3C for ; Wed, 16 Sep 2020 15:31:34 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id p9so10944830ejf.6 for ; Wed, 16 Sep 2020 08:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=FFVIMLw/qCsSLnB7Hf2n5qox/a9OEmYxxlddH5dk/ng=; b=NonqZq3rUzQcLEzLa0eBBE1h+gfBuDVn6anZ5i79FdEzJ+JYlB5SF7WfWfG3Mqvcrz mpBRMc8amwyC7GvLim/gZecRiJ0vOCz1yEPW5AGY5gdgIiAxVnKaz6+8cQWgOOE1JBWo umZ7lUC4fu6kdAIr/pLSd3uACF3Leq/HOcTZ1qLED+2Dh1I4zZFDqYA3g7QkB/mkQbHh cq+zcHmwJnCTpRvWYKWZ+sW6FV/DqDnOPIEaE1u4XZmMa77U6nIxauuufDzKAfmeZ6Cl CnFDeB1TboTcq3DxTXjkmIxcdUlTEg1NlZE99ETZER7DASL0l92c2vwTdrneuKiaL0fS h6UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=FFVIMLw/qCsSLnB7Hf2n5qox/a9OEmYxxlddH5dk/ng=; b=Jwd2u1HqoBuyXE5i+M7V/Sj/Hrs+j0bOVJ2bchYjHSJPKfXp+BaegnnXusl6LQ8eQZ fU4U9hSfcgeaUS1ZO+S2v+Rc8z/VvBLqHQdW1zm5DMo1fFuttmHfaD98lAoxuk7ojKgR 1JgfVvEQzM0a9IQimEZZeMM1ijb0CAbWDWOVv7VwND4AkMmklUjvkbgwSLwPbg2so8s8 VnQuyRSmJSqdlynDjHUztBR6PoQlv8tFsDJTMDJPseHELxiITSuhvuuePDDNM2TSV2Ge fTlxxUZrpMRvk75wqFMfXNT8PyQ9h0Tv2YO6JyJdcmJHUgU4DLRNH88iqTJ8W+5UJEKm lYMg== X-Gm-Message-State: AOAM530g8jowMPAn584E+j327/iZZRj/2vq0kS81x1H7Z1mR/YPCAdRC w1kTCjE0B9jeJUZygNbuXLw= X-Google-Smtp-Source: ABdhPJx8ArZnxCH5L/M6w2OQ/SkKcPuPpgnzuN/T5LBMYwHsyZz643N/8p/J/r8TnQEqdpzY+GTdEQ== X-Received: by 2002:a17:906:d965:: with SMTP id rp5mr25015415ejb.364.1600270293644; Wed, 16 Sep 2020 08:31:33 -0700 (PDT) Received: from ?IPv6:2a02:908:1252:fb60:be8a:bd56:1f94:86e7? ([2a02:908:1252:fb60:be8a:bd56:1f94:86e7]) by smtp.gmail.com with ESMTPSA id lo25sm12877150ejb.53.2020.09.16.08.31.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2020 08:31:33 -0700 (PDT) Subject: Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap() To: Daniel Vetter , =?UTF-8?Q?Christian_K=c3=b6nig?= References: <20200914132920.59183-1-christian.koenig@amd.com> <40cd26ae-b855-4627-5a13-4dcea5d622f6@gmail.com> <20200914140632.GD1221970@ziepe.ca> <9302e4e0-0ff0-8b00-ada1-85feefb49e88@gmail.com> <20200916095359.GD438822@phenom.ffwll.local> <20200916140710.GA8409@ziepe.ca> <8db2474f-ecb7-0e17-5f5b-145708fe44d5@amd.com> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Wed, 16 Sep 2020 17:31:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: christian.koenig@amd.com Cc: Jason Gunthorpe , Linux Kernel Mailing List , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Linux MM , Andrew Morton , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" QW0gMTYuMDkuMjAgdW0gMTc6MjQgc2NocmllYiBEYW5pZWwgVmV0dGVyOgo+IE9uIFdlZCwgU2Vw IDE2LCAyMDIwIGF0IDQ6MTQgUE0gQ2hyaXN0aWFuIEvDtm5pZwo+IDxjaHJpc3RpYW4ua29lbmln QGFtZC5jb20+IHdyb3RlOgo+PiBBbSAxNi4wOS4yMCB1bSAxNjowNyBzY2hyaWViIEphc29uIEd1 bnRob3JwZToKPj4+IE9uIFdlZCwgU2VwIDE2LCAyMDIwIGF0IDExOjUzOjU5QU0gKzAyMDAsIERh bmllbCBWZXR0ZXIgd3JvdGU6Cj4+Pgo+Pj4+IEJ1dCB3aXRoaW4gdGhlIGRyaXZlciwgd2UgZ2Vu ZXJhbGx5IG5lZWQgdGhvdXNhbmRzIG9mIHRoZXNlLCBhbmQgdGhhdAo+Pj4+IHRlbmRzIHRvIGJy aW5nIGZkIGV4aGF1c3Rpb24gcHJvYmxlbXMgd2l0aCBpdC4gVGhhdCdzIHdoeSBhbGwgdGhlIHBy aXZhdGUKPj4+PiBidWZmZXIgb2JqZWN0cyB3aGljaCBhcmVuJ3Qgc2hhcmVkIHdpdGggb3RoZXIg cHJvY2VzcyBvciBvdGhlciBkcml2ZXJzIGFyZQo+Pj4+IGhhbmRsZXMgb25seSB2YWxpZCBmb3Ig YSBzcGVjaWZpYyBmZCBpbnN0YW5jZSBvZiB0aGUgZHJtIGNoYXJkZXYgKGVhY2gKPj4+PiBvcGVu IGdldHMgdGhlaXIgb3duIG5hbWVzcGFjZSksIGFuZCBvbmx5IGZvciBpb2N0bHMgZG9uZSBvbiB0 aGF0IGNoYXJkZXYuCj4+Pj4gQW5kIGZvciBtbWFwIHdlIGFzc2lnbiBmYWtlIChidXQgdW5pcXVl IGFjcm9zcyBhbGwgb3BlbiBmZCBvbiBpdCkgb2Zmc2V0cwo+Pj4+IHdpdGhpbiB0aGUgb3ZlcmFs bCBjaGFyZGV2LiBIZW5jZSBhbGwgdGhlIHBnb2ZmIG1hbmdsaW5nIGFuZCByZS1tYW5nbGluZy4K Pj4+IEFyZSB0aGV5IHN0aWxsIHVuaXF1ZSBzdHJ1Y3QgZmlsZXM/IEp1c3Qgd2l0aG91dCBhIGZk bm8/Cj4+IFllcywgZXhhY3RseS4KPiBOb3QgZW50aXJlbHksIHNpbmNlIGRtYS1idWYgaGFwcGVu ZWQgYWZ0ZXIgZHJtIGNoYXJkZXYsIHNvIGZvciB0aGF0Cj4gaGlzdG9yaWNhbCByZWFzb24gdGhl IHVuZGVybHlpbmcgc3RydWN0IGZpbGUgaXMgc2hhcmVkLCBzaW5jZSBpdCdzIHRoZQo+IGRybSBj aGFyZGV2LiBCdXQgc2luY2UgdGhhdCdzIHBlci1kZXZpY2Ugd2UgZG9uJ3QgaGF2ZSBhIHByb2Js ZW0gaW4KPiBwcmFjdGljZSB3aXRoIGRpZmZlcmVudCB2bV9vcHMsIHNpbmNlIHRob3NlIGFyZSBh bHNvIHBlci1kZXZpY2UuIEJ1dAo+IHllYWggd2UgY291bGQgZmlzaCBvdXQgc29tZSBlbnRpcmVs eSBoaWRkZW4gcGVyLW9iamVjdCBzdHJ1Y3QgZmlsZSBpZgo+IHRoYXQncyByZXF1aXJlZCBmb3Ig c29tZSBtbSBpbnRlcm5hbCByZWFzb25zLgoKSHVpPyBPayB0aGF0IGlzIGp1c3QgdGhlIGhhbmRs aW5nIGluIGk5MTUsIGlzbid0IGl0PwoKQXMgZmFyIGFzIEkga25vdyB3ZSBjcmVhdGUgYW4gdW5p cXVlIHN0cnVjdCBmaWxlIGZvciBlYWNoIERNQS1idWYuCgpSZWdhcmRzLApDaHJpc3RpYW4uCgoK PiAtRGFuaWVsCj4KPj4+PiBIZW5jZSB3aHkgd2UnZCBsaWtlIHRvIGJlIGFibGUgdG8gZm9yd2Fy ZCBhbGlhc2luZyBtYXBwaW5ncyBhbmQgYWRqdXN0IHRoZQo+Pj4+IGZpbGUgYW5kIHBnb2ZmLCB3 aGlsZSBob3BlZnVsbHkgZXZlcnl0aGluZyBrZWVwcyB3b3JraW5nLiBJIHRob3VnaHQgdGhpcwo+ Pj4+IHdvdWxkIHdvcmssIGJ1dCBDaHJpc3RpYW4gbm90aWNlZCBpdCBkb2Vzbid0IHJlYWxseS4K Pj4+IEl0IHNlZW1zIHJlYXNvbmFibGUgdG8gbWUgdGhhdCB0aGUgZG1hIGJ1ZiBzaG91bGQgYmUg dGhlIG93bmVyIG9mIHRoZQo+Pj4gVk1BLCBvdGhlcndpc2UgbGlrZSB5b3Ugc2F5LCB0aGVyZSBp cyBhIGJpZyBtZXNzIGF0dGFjaGluZyB0aGUgY3VzdG9tCj4+PiB2bWEgb3BzIGFuZCB3aGF0IG5v dCB0byB0aGUgcHJvcGVyIGRtYSBidWYuCj4+Pgo+Pj4gSSBkb24ndCBzZWUgYW55dGhpbmcgb2J2 aW91c2x5IGFnYWluc3QgdGhpcyBpbiBtbWFwX3JlZ2lvbigpIC0gd2h5IGRpZAo+Pj4gQ2hyaXRp YW4gbm90aWNlIGl0IGRvZXNuJ3QgcmVhbGx5IHdvcms/Cj4+IFRvIGNsYXJpZnkgSSB0aGluayB0 aGlzIG1pZ2h0IHdvcmsuCj4+Cj4+IEkganVzdCBoYWQgdGhlIHNhbWUgIklzIHRoYXQgbGVnYWw/ IiwgIldoYXQgYWJvdXQgc2VjdXJpdHk/IiwgZXRjLi4KPj4gcXVlc3Rpb25zIHlvdSByYWlzZWQg YXMgd2VsbC4KPj4KPj4gSXQgc2VlbXMgbGlrZSBhIHNvdXJjZSBvZiB0cm91YmxlIHNvIEkgdGhv dWdodCBiZXR0ZXIgYXNrIHNvbWVib2R5IG1vcmUKPj4gZmFtaWxpYXIgd2l0aCB0aGF0Lgo+Pgo+ PiBDaHJpc3RpYW4uCj4+Cj4+PiBKYXNvbgo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+PiBkcmktZGV2ZWwgbWFpbGluZyBsaXN0Cj4+IGRyaS1kZXZl bEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKPj4gaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcv bWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwKPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBs aXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1h bi9saXN0aW5mby9kcmktZGV2ZWwK 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=-5.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,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 3ED19C43461 for ; Wed, 16 Sep 2020 19:09:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DF4C920715 for ; Wed, 16 Sep 2020 19:09:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NonqZq3r" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727751AbgIPTJ2 (ORCPT ); Wed, 16 Sep 2020 15:09:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727356AbgIPRoZ (ORCPT ); Wed, 16 Sep 2020 13:44:25 -0400 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4882FC061356; Wed, 16 Sep 2020 08:31:35 -0700 (PDT) Received: by mail-ej1-x641.google.com with SMTP id r7so10924982ejs.11; Wed, 16 Sep 2020 08:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=FFVIMLw/qCsSLnB7Hf2n5qox/a9OEmYxxlddH5dk/ng=; b=NonqZq3rUzQcLEzLa0eBBE1h+gfBuDVn6anZ5i79FdEzJ+JYlB5SF7WfWfG3Mqvcrz mpBRMc8amwyC7GvLim/gZecRiJ0vOCz1yEPW5AGY5gdgIiAxVnKaz6+8cQWgOOE1JBWo umZ7lUC4fu6kdAIr/pLSd3uACF3Leq/HOcTZ1qLED+2Dh1I4zZFDqYA3g7QkB/mkQbHh cq+zcHmwJnCTpRvWYKWZ+sW6FV/DqDnOPIEaE1u4XZmMa77U6nIxauuufDzKAfmeZ6Cl CnFDeB1TboTcq3DxTXjkmIxcdUlTEg1NlZE99ETZER7DASL0l92c2vwTdrneuKiaL0fS h6UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=FFVIMLw/qCsSLnB7Hf2n5qox/a9OEmYxxlddH5dk/ng=; b=swWJmTWlJn5fxdz9nnCIa8Fe7F3PfxegyeIVlYFpR94AF4UnI0RuTUE4HlRLFhqDt+ TiaYyxM/kEVDVQCLwsRLpPXJ85NZAt3SO67a6x2woEIrvA8IRNRbFsvKGCo30ThQUqe2 m5qjlC2RTKhn0IwhSOe2ku6z9mfPum6g2K4lLxclUQ6kUjsZyJVNDwxbhD259F06t0tZ CwuZBXpNy3nqHznryOIuAcQtnH/5+pb1jum4xp/ejOAEAWW6E91T6zepg/aTxgHFvlbn +eUUDO6iUZNk5LtiLRDJDJokwA3ucE5qdo9kfnI+MEw0hhZtwdRihamPZTeqnQdqSgZr jYZA== X-Gm-Message-State: AOAM532ITPC2UYgbveIDfCazGgPsW4V52xJMflL53Gw4We6pXZ86Xm4Y scMKp9qQL0q5wrD5o+YL0g+2Mk+7CJU= X-Google-Smtp-Source: ABdhPJx8ArZnxCH5L/M6w2OQ/SkKcPuPpgnzuN/T5LBMYwHsyZz643N/8p/J/r8TnQEqdpzY+GTdEQ== X-Received: by 2002:a17:906:d965:: with SMTP id rp5mr25015415ejb.364.1600270293644; Wed, 16 Sep 2020 08:31:33 -0700 (PDT) Received: from ?IPv6:2a02:908:1252:fb60:be8a:bd56:1f94:86e7? ([2a02:908:1252:fb60:be8a:bd56:1f94:86e7]) by smtp.gmail.com with ESMTPSA id lo25sm12877150ejb.53.2020.09.16.08.31.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2020 08:31:33 -0700 (PDT) Reply-To: christian.koenig@amd.com Subject: Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap() To: Daniel Vetter , =?UTF-8?Q?Christian_K=c3=b6nig?= Cc: Linux MM , Linux Kernel Mailing List , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Jason Gunthorpe , Andrew Morton , "open list:DMA BUFFER SHARING FRAMEWORK" References: <20200914132920.59183-1-christian.koenig@amd.com> <40cd26ae-b855-4627-5a13-4dcea5d622f6@gmail.com> <20200914140632.GD1221970@ziepe.ca> <9302e4e0-0ff0-8b00-ada1-85feefb49e88@gmail.com> <20200916095359.GD438822@phenom.ffwll.local> <20200916140710.GA8409@ziepe.ca> <8db2474f-ecb7-0e17-5f5b-145708fe44d5@amd.com> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Wed, 16 Sep 2020 17:31:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Am 16.09.20 um 17:24 schrieb Daniel Vetter: > On Wed, Sep 16, 2020 at 4:14 PM Christian König > wrote: >> Am 16.09.20 um 16:07 schrieb Jason Gunthorpe: >>> On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote: >>> >>>> But within the driver, we generally need thousands of these, and that >>>> tends to bring fd exhaustion problems with it. That's why all the private >>>> buffer objects which aren't shared with other process or other drivers are >>>> handles only valid for a specific fd instance of the drm chardev (each >>>> open gets their own namespace), and only for ioctls done on that chardev. >>>> And for mmap we assign fake (but unique across all open fd on it) offsets >>>> within the overall chardev. Hence all the pgoff mangling and re-mangling. >>> Are they still unique struct files? Just without a fdno? >> Yes, exactly. > Not entirely, since dma-buf happened after drm chardev, so for that > historical reason the underlying struct file is shared, since it's the > drm chardev. But since that's per-device we don't have a problem in > practice with different vm_ops, since those are also per-device. But > yeah we could fish out some entirely hidden per-object struct file if > that's required for some mm internal reasons. Hui? Ok that is just the handling in i915, isn't it? As far as I know we create an unique struct file for each DMA-buf. Regards, Christian. > -Daniel > >>>> Hence why we'd like to be able to forward aliasing mappings and adjust the >>>> file and pgoff, while hopefully everything keeps working. I thought this >>>> would work, but Christian noticed it doesn't really. >>> It seems reasonable to me that the dma buf should be the owner of the >>> VMA, otherwise like you say, there is a big mess attaching the custom >>> vma ops and what not to the proper dma buf. >>> >>> I don't see anything obviously against this in mmap_region() - why did >>> Chritian notice it doesn't really work? >> To clarify I think this might work. >> >> I just had the same "Is that legal?", "What about security?", etc.. >> questions you raised as well. >> >> It seems like a source of trouble so I thought better ask somebody more >> familiar with that. >> >> Christian. >> >>> Jason >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >