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.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 BE24EC43461 for ; Thu, 17 Sep 2020 15:37:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C638A2222D for ; Thu, 17 Sep 2020 15:37:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="ISCJ5Tw6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C638A2222D 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 0DF188E0003; Thu, 17 Sep 2020 11:37:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 090888E0001; Thu, 17 Sep 2020 11:37:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE7D68E0003; Thu, 17 Sep 2020 11:37:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0181.hostedemail.com [216.40.44.181]) by kanga.kvack.org (Postfix) with ESMTP id D8EA48E0001 for ; Thu, 17 Sep 2020 11:37:15 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 7812521E4 for ; Thu, 17 Sep 2020 15:37:15 +0000 (UTC) X-FDA: 77272957230.06.pest03_290efdd27123 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id 490F610067AA4 for ; Thu, 17 Sep 2020 15:37:15 +0000 (UTC) X-HE-Tag: pest03_290efdd27123 X-Filterd-Recvd-Size: 7106 Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Sep 2020 15:37:14 +0000 (UTC) Received: by mail-ot1-f67.google.com with SMTP id q21so2290165ota.8 for ; Thu, 17 Sep 2020 08:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZKdwGNTuB7raHchRws1uZpYC5kiBgIgkW7sRbNdes8U=; b=ISCJ5Tw66UvgaeWJoGMvoGpBgdi+Pvh73WzxPCKZycvbr4Kw5zYOwmcCQjHLfF+3da CYy+53x/nyxrzX0KXw6ljYFdDcKO3M9i08qHW5NqtLtlz6ZhbasQ8xieyUjx4qmoUfzZ Zbi23eh19F5Vb4GtV/XcziMcnv0MJy1iuV014= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZKdwGNTuB7raHchRws1uZpYC5kiBgIgkW7sRbNdes8U=; b=RydZutvZQGK5a3w7nc310JfluoEHe3pMyulfmthHJ99Hg1jWcUV1dBB97dNbeY5iuQ PNj1RdgggooU+wOVlTMWfJIFLfoKeIYkSMSakMkUJ9tr9fTmRNQSRhWIkBl/LMAd7qcj 01OSUa1UsVcTo+NaDMtGEKj4rrXBnAGtbUMYLzWUU4gdH7UWXXFpCo8hg6ySOqSOv69J qAtgIYyrgI5zayLcZ7BJcnYSdhaAdYFv3Nh2XyucmMGnTa6JsCm8fG252Qjz4qsfpTYW IUwAqDyoSRANTXQsQyskd6RrRaHApWlC2ELbcqlHcuetnjEOsYLDxrpNa+qCEFMoc2+Z /LbQ== X-Gm-Message-State: AOAM531BQ+OMy8iZhJFVeZwzyYVId6qXuDWAGb/WgheFGsbNnUXCSkaY rU7glFsK9/fkNx6cvQEmOaTrYjxzfRKHJf6uVXOQOA== X-Google-Smtp-Source: ABdhPJzGgOa/Oz2wRUro/hKXS9FrrveYmtnBfxpRy+S4Y7u9DCAavZtFsw1BfFfAu8kbrs7cNgN2/BHLCGrXvdc8BOY= X-Received: by 2002:a05:6830:14d9:: with SMTP id t25mr21146655otq.188.1600357033519; Thu, 17 Sep 2020 08:37:13 -0700 (PDT) MIME-Version: 1.0 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> <20200917152456.GH8409@ziepe.ca> In-Reply-To: <20200917152456.GH8409@ziepe.ca> From: Daniel Vetter Date: Thu, 17 Sep 2020 17:37:01 +0200 Message-ID: Subject: Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap() To: Jason Gunthorpe Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , Linux Kernel Mailing List , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Linux MM , Andrew Morton , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 490F610067AA4 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 5:24 PM Jason Gunthorpe wrote: > > 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= : > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > 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. > > > > > > > > > > > > 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 > > > > > > > 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 > > > > 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. Uh geez I didn't know amdgpu was doing that :-/ Since this is on, I guess the inverse of trying to convert a userptr into a dma-buf is properly rejected? > 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? Nope. I think if you want this without some large scale rewrite of a lot of code we'd need a vmops->get_dmabuf or similar. Not pretty, but would get the job done. > > > So, user VA -> find_vma -> dma_buf object -> dma_buf operations on th= e > > > memory it represents > > > > 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 Mostly historical reasons and "it's complicated". One problem is that dma-buf isn't a powerful enough interface that drivers could use it for all their native objects, e.g. userptr doesn't pass through it, and clever cache flushing tricks aren't allowed and a bunch of other things. So there's some serious roadblocks before we could have a common allocator (or set of allocators) behind dma-buf. -Daniel --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch