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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 EAA2EC43461 for ; Thu, 17 Sep 2020 12:26:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8992208DB for ; Thu, 17 Sep 2020 12:26:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="IVQpQa30" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8992208DB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2611C6B0055; Thu, 17 Sep 2020 08:26:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20F5B6B005A; Thu, 17 Sep 2020 08:26:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D7966B005C; Thu, 17 Sep 2020 08:26:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EC5196B0055 for ; Thu, 17 Sep 2020 08:26:42 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9B2823636 for ; Thu, 17 Sep 2020 12:26:42 +0000 (UTC) X-FDA: 77272477044.13.year53_1603fb727122 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 9777618140B75 for ; Thu, 17 Sep 2020 12:26:41 +0000 (UTC) X-HE-Tag: year53_1603fb727122 X-Filterd-Recvd-Size: 6237 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Sep 2020 12:26:40 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id m6so1878822wrn.0 for ; Thu, 17 Sep 2020 05:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=776kE571jxALYsOg06ejCyM2zHb/SfLHRc5/m8v10ss=; b=IVQpQa30jthrbYlgwDGmu0dc3mjMkTqbdMKMaSnRvLnHMKlNvHBoPDQ8r760u+SVPm 59vgHhoVxmVxKNvGKFX9QbbbOEpWzNWMXSHfbRt/bDygT1XUo/rI/mTP8lwcUxWU928G cOYIpmnvb7A0tsT+gMKdSIF7Iz7lnU7Ky2wTs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=776kE571jxALYsOg06ejCyM2zHb/SfLHRc5/m8v10ss=; b=WZAaujtETv3sIVqxTEuuqZSjZVm92TpL+Jv5zbRX3dFwBW3HTCYdM5w1we2JjhcULr 6e9k7Go83+Pn1Bdvt7zb71O0JQ7VHUQM1fHYuox/2z+TUfhdvlZtg2NmACXt4ZbFoVM8 msUPLgOZiRD+zlYYUbrCYEZ99vynMHP+iYZPPawRiscxf/P2t4Sj0C7vb6TOFBKVXWwT OfjyYsr8ZfYaV7XzXSmHEccmlco87T8c+w6+80WzvCsubCwkYjvtCba2J+YgmWUOiwMT e/Usaak06ppXRjPZ2sm8udr7cb91qPKDbe+eCIurWPcp3x+wvasM7WBWe3O07ClCH7yo FAFg== X-Gm-Message-State: AOAM530/EyfTWeMXUf4CIu79qMoA9utKsi47plQTKZAPhIcgrae7nS2X jCJlwBoKbgn3uaNjxx31Slue0A== X-Google-Smtp-Source: ABdhPJxsVUfr3DZLp2Gh7FRSChhAJlPPexeSjbdhob6/sk140ihZIXopzA3J7Zp+4xfpjlTSOU6Fyg== X-Received: by 2002:a5d:4a49:: with SMTP id v9mr34943739wrs.153.1600345599608; Thu, 17 Sep 2020 05:26:39 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id u186sm10458866wmu.34.2020.09.17.05.26.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Sep 2020 05:26:38 -0700 (PDT) Date: Thu, 17 Sep 2020 14:26:36 +0200 From: Daniel Vetter To: christian.koenig@amd.com Cc: Jason Gunthorpe , Linux Kernel Mailing List , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Linux MM , Daniel Vetter , Andrew Morton , "open list:DMA BUFFER SHARING FRAMEWORK" Subject: Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap() Message-ID: <20200917122636.GW438822@phenom.ffwll.local> Mail-Followup-To: christian.koenig@amd.com, Jason Gunthorpe , Linux Kernel Mailing List , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Linux MM , Andrew Morton , "open list:DMA BUFFER SHARING FRAMEWORK" References: <8db2474f-ecb7-0e17-5f5b-145708fe44d5@amd.com> <8d8693db-a3f0-4f5f-3e32-57d23ca620f8@amd.com> <20200917113110.GE8409@ziepe.ca> <6fd74b84-959c-8b3b-c27b-e9fbf66396c7@gmail.com> <20200917121858.GF8409@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.7.0-1-amd64 X-Rspamd-Queue-Id: 9777618140B75 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 Content-Transfer-Encoding: quoted-printable 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: On Thu, Sep 17, 2020 at 02:24:29PM +0200, Christian K=F6nig wrote: > Am 17.09.20 um 14:18 schrieb Jason Gunthorpe: > > On Thu, Sep 17, 2020 at 02:03:48PM +0200, Christian K=F6nig wrote: > > > Am 17.09.20 um 13:31 schrieb Jason Gunthorpe: > > > > On Thu, Sep 17, 2020 at 10:09:12AM +0200, Daniel Vetter wrote: > > > >=20 > > > > > Yeah, but it doesn't work when forwarding from the drm chardev = to the > > > > > dma-buf on the importer side, since you'd need a ton of differe= nt > > > > > address spaces. And you still rely on the core code picking up = your > > > > > pgoff mangling, which feels about as risky to me as the vma fil= e > > > > > pointer wrangling - if it's not consistently applied the revers= e map > > > > > is toast and unmap_mapping_range doesn't work correctly for our= needs. > > > > I would think the pgoff has to be translated at the same time the > > > > vm->vm_file is changed? > > > >=20 > > > > The owner of the dma_buf should have one virtual address space an= d FD, > > > > all its dma bufs should be linked to it, and all pgoffs translate= d to > > > > that space. > > > Yeah, that is exactly like amdgpu is doing it. > > >=20 > > > Going to document that somehow when I'm done with TTM cleanups. > > BTW, while people are looking at this, is there a way to go from a VM= A > > to a dma_buf that owns it? >=20 > Only a driver specific one. >=20 > For TTM drivers vma->vm_private_data points to the buffer object. Not s= ure > about the drivers using GEM only. For gem drivers (which includes the ones using vram helpers, which uses ttm internally) that points at the drm_gem_object pointer. I guess that might be something we can unify a bit on the ttm mmap paths of the remaining driver, now that there's a drm_gem_object embedded anyway. -Daniel >=20 > Why are you asking? >=20 > Regards, > Christian. >=20 > >=20 > > Jason > > _______________________________________________ > > Linaro-mm-sig mailing list > > Linaro-mm-sig@lists.linaro.org > > https://lists.linaro.org/mailman/listinfo/linaro-mm-sig >=20 --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch