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 F0251C2BBD1 for ; Thu, 17 Sep 2020 17:23:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E2645221E3 for ; Thu, 17 Sep 2020 17:23:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="Oe+9XFyi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2645221E3 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 65B006B0087; Thu, 17 Sep 2020 13:23:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60AB88E0001; Thu, 17 Sep 2020 13:23:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AAB76B008A; Thu, 17 Sep 2020 13:23:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0184.hostedemail.com [216.40.44.184]) by kanga.kvack.org (Postfix) with ESMTP id 345ED6B0087 for ; Thu, 17 Sep 2020 13:23:16 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 012DE180AD81F for ; Thu, 17 Sep 2020 17:23:15 +0000 (UTC) X-FDA: 77273224392.03.way96_1a0526527124 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id D109228A4E8 for ; Thu, 17 Sep 2020 17:23:15 +0000 (UTC) X-HE-Tag: way96_1a0526527124 X-Filterd-Recvd-Size: 4937 Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Sep 2020 17:23:15 +0000 (UTC) Received: by mail-oi1-f193.google.com with SMTP id x69so3341573oia.8 for ; Thu, 17 Sep 2020 10:23: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=F86p0ud99YSiTMCN0ZfJJse9lFQfi+WRyzF06l3LfwA=; b=Oe+9XFyi4XwSdp0c08MIQlmhrPw1Z8ltKB2S7V3IMBblrL34HKoK0b4blCy3ZHSJxj 7IaJJ0RwaRrjJztcw/95TWgK1iToMprnqvda3Cw5Rs+2ciTDAeh8nMCt44s2ulVhn6KN 6sAVjFYZRVuJFjONKZdpeD53O77tF58gs1uyI= 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=F86p0ud99YSiTMCN0ZfJJse9lFQfi+WRyzF06l3LfwA=; b=afAL9BiPtjVKJNEiVFTYfROrzj9BlfAvVGROgTjbqL6A+xymeEPTpDG7npLUWqh9v0 oAntCeMAwyLq79Kvi3z3BhAe8NdiefoROXOp7JbnUsy9wGSqHa3CRRgIIBqzso2Wn1ok Y7ZfOcquOAjki7U+mLlE3QPcPSjptl98ZAKwMljh7M8r3r2IlIGDccuMqDcILgWnGLot wTsm4METQAgm20kqHi9nzLfbaFqv4KtAvjICkQ7qrqcW72Lf14PciEHLVBwUimO555PX OddAqA/bnDSuwEyy24oK8bk48OSGwa41RAXYdcyYfkL8xRBIjINb5XccxAwp0Ibtrfah vaUQ== X-Gm-Message-State: AOAM533stwDa1mwTi4+4IIeSeznxQ0pZHrtDEwCUpvEdd4SUdo94+/E2 MwHCNKIH5hevHDv89Gpsg+iP8langZTdfFEenJgVXA== X-Google-Smtp-Source: ABdhPJwF3dNmQNnc08BdxH8My7DtOBpKWMR10LzO7dt3VFCMGmJE1UwcTFFGHLsdQ5ho5h5wrPc5sUf6w5ZuU6y8//k= X-Received: by 2002:aca:6083:: with SMTP id u125mr7050119oib.14.1600363394219; Thu, 17 Sep 2020 10:23:14 -0700 (PDT) MIME-Version: 1.0 References: <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> <20200917163907.GI8409@ziepe.ca> In-Reply-To: <20200917163907.GI8409@ziepe.ca> From: Daniel Vetter Date: Thu, 17 Sep 2020 19:23:03 +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-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 6:39 PM Jason Gunthorpe wrote: > > On Thu, Sep 17, 2020 at 06:06:14PM +0200, Christian K=C3=B6nig wrote: > > > > If it is already taking a page fault I'm not sure the extra functio= n > > > > 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 t= he > > > > drivers turned out to be generally buggy, at least. > > > > > > > > Is vma->vm_file->private_data universally a dma_buf pointer at leas= t? > > > 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. > > > > Yeah, agree that sounds like the simplest approach. > > I don't think that will fly, it is clearly only papering over a mess > inside DRM/dma buf :\ dma-buf started out as something to paper over the disjoint mess of allocators, since it was pretty clear to anyone involved we're not going to unify them anytime soon, if ever. So the mess pretty much is bound to stay. I think most reasonable thing would be to throw a common vmops in there somehow, but even that means some large scale surgery across every driver/subsystem involved in dma-buf. It wouldn't unify anything, all it would give you is a constant vma->vm_ops to do some kind of upcasting. And that would still only give you a slightly less opaque pointer with a callback to upcast to a dma-buf in some driver/subsystem specific way. -Daniel --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch