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 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 6088FC43461 for ; Thu, 17 Sep 2020 15:25:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AE12F21973 for ; Thu, 17 Sep 2020 15:25:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="KItZq7TL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE12F21973 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BD4846B0055; Thu, 17 Sep 2020 11:24:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B86116B005A; Thu, 17 Sep 2020 11:24:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4CCF6B0062; Thu, 17 Sep 2020 11:24:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id 9056E6B0055 for ; Thu, 17 Sep 2020 11:24:59 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 42C438249980 for ; Thu, 17 Sep 2020 15:24:59 +0000 (UTC) X-FDA: 77272926318.28.neck59_0e15ce827123 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 130DA6C0B for ; Thu, 17 Sep 2020 15:24:59 +0000 (UTC) X-HE-Tag: neck59_0e15ce827123 X-Filterd-Recvd-Size: 6691 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Sep 2020 15:24:58 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id k25so2169563qtu.4 for ; Thu, 17 Sep 2020 08:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=/MIjfA84FROcmh2Yr+++vHpa0nobfYfMg9k42KNVp2M=; b=KItZq7TLRwXkeSUDV7TVakSYOYYpYVj1lFuOvU0VuV2nyeTZkDl+5SDk5YU6xRfdQb mmJrGXwRgXiqpqZBf8DLOJr/gMeGErqhZkM8rZSmNzY3KpK/NJt55cQb3C29WXfmsp40 KJdpWLxQBDyknwAoYt/ULy2EsSn//x6zNDDJW/sQmVP1idUubfNstwrhi9t017rZ3QZJ 3sDqFSKs5FzHiMnyyMyLtAnPX0Naf0m0oIbzEeYFHkliee0CZ1/6R0VN7TcyiVwxLFrO JOOOGOMacxM9ezg1v7YEt3scmLEmwNPGkyrd88i/jnPrnz/LvnJkdxDuuHZJUSvAh0TC tmSA== 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:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=/MIjfA84FROcmh2Yr+++vHpa0nobfYfMg9k42KNVp2M=; b=lmSSh8UWe6jtjwqYtYlaR0Fhy+yx2YT8s3v9+VE9AWjU9jSsNtNOthCUwjsjfNtjr6 OyZCYgYGMUixdhew9Ph+FSo5f1DM98k465ngI60q6GBeuTwPRccJ43loeXt2Qf3zxeEi y9ubVzR+P1lNDqwc4asdbBc/4HmnNtCP89lna4ZlyqMz04ruXT1f1cFXWcpbJe/mfKaT oM/iIdM5B2fnMcaKUm+0TryVeiDDSP6a3NX2p9G48JjtiiA6Rb+SoqjFm1zg8vLPreAG 9MrnegPvnmiSCwJg0Yy/VLpy3kr6zHcZBmiKCQ9rNraC/KPkD8bRxLfaHUKnqProTRqF gB2Q== X-Gm-Message-State: AOAM530eW0xbuBCWzFlrgRcf7rsw4OwynYhz6PuxORwXB9I5mNgrCxjV 4qtACzjFao3RyQKTgg73BRl2Yw== X-Google-Smtp-Source: ABdhPJyml2ehbabsQ2p5uBo50b15HPhlS1qE50x7EQpnsGFfmEF+Ym7+K38vhRLvzw2lQSd1AWRM1Q== X-Received: by 2002:ac8:5d04:: with SMTP id f4mr16143583qtx.290.1600356297898; Thu, 17 Sep 2020 08:24:57 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id z74sm86638qkb.11.2020.09.17.08.24.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Sep 2020 08:24:57 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kIvmK-000VsL-KF; Thu, 17 Sep 2020 12:24:56 -0300 Date: Thu, 17 Sep 2020 12:24:56 -0300 From: Jason Gunthorpe To: christian.koenig@amd.com Cc: 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: <20200917152456.GH8409@ziepe.ca> References: <8d8693db-a3f0-4f5f-3e32-57d23ca620f8@amd.com> <20200917113110.GE8409@ziepe.ca> <6fd74b84-959c-8b3b-c27b-e9fbf66396c7@gmail.com> <20200917121858.GF8409@ziepe.ca> <20200917143551.GG8409@ziepe.ca> <5b330920-c789-fac7-e9b1-49f3bc1097a8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5b330920-c789-fac7-e9b1-49f3bc1097a8@gmail.com> X-Rspamd-Queue-Id: 130DA6C0B 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 04:54:44PM +0200, Christian K=C3=B6nig wrote: > Am 17.09.20 um 16:35 schrieb Jason Gunthorpe: > > On Thu, Sep 17, 2020 at 02:24:29PM +0200, Christian K=C3=B6nig wrote: > > > Am 17.09.20 um 14:18 schrieb Jason Gunthorpe: > > > > On Thu, Sep 17, 2020 at 02:03:48PM +0200, Christian K=C3=B6nig wr= ote: > > > > > 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 char= dev to the > > > > > > > dma-buf on the importer side, since you'd need a ton of dif= ferent > > > > > > > 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= file > > > > > > > pointer wrangling - if it's not consistently applied the re= verse 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 spac= e and FD, > > > > > > all its dma bufs should be linked to it, and all pgoffs trans= lated 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 VMA > > > > to a dma_buf that owns it? > > > Only a driver specific one. > > Sounds OK > >=20 > > > For TTM drivers vma->vm_private_data points to the buffer object. N= ot sure > > > about the drivers using GEM only. > > Why are drivers in control of the vma? I would think dma_buf should b= e > > the vma owner. IIRC module lifetime correctness essentially hings on > > the module owner of the struct file >=20 > Because the page fault handling is completely driver specific. > > We could install some DMA-buf vmops, but that would just be another lay= er of > redirection. If it is already taking a page fault I'm not sure the extra function call indirection is going to be a big deal. Having a uniform VMA sounds saner than every driver custom rolling something. When I unwound a similar mess in RDMA all the custom VMA stuff in the drivers turned out to be generally buggy, at least. Is vma->vm_file->private_data universally a dma_buf pointer at least? > > So, user VA -> find_vma -> dma_buf object -> dma_buf operations on th= e > > memory it represents >=20 > Ah, yes we are already doing this in amdgpu as well. But only for DMA-b= ufs > or more generally buffers which are mmaped by this driver instance. So there is no general dma_buf service? That is a real bummer Jason