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 F29EDC433E2 for ; Thu, 17 Sep 2020 17:24:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AF36E221E3 for ; Thu, 17 Sep 2020 17:24:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="Oe+9XFyi" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726419AbgIQRXs (ORCPT ); Thu, 17 Sep 2020 13:23:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726390AbgIQRXX (ORCPT ); Thu, 17 Sep 2020 13:23:23 -0400 Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C94B0C061756 for ; Thu, 17 Sep 2020 10:23:14 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id z26so3309697oih.12 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=iYvHEOo+NPuNfKMDZGAcPIAGtQPBEx9qMVG7jju+i3ZAYZEmi+aKZiot3hpKSqnY85 61+v2EJLAJ3kcXPA5e1VFSuEruUmtouPRb/ksJrY3GQpjGweVQJlwhbrRU7GIw5p++ql PmDMSRJ8KsivnnFyKPqH4DPv/hgvvr35l8YPYPS7sR8nNw0vbjHhp7DGdJ9XZmRT0D6n BxkzEwSavr5bvCh1tjfIH9Y8QoWYcq6Utq3W8XUbVUZsdkDEIXYLGXiIrzKzZrGhhF7u LWwowbv2QXKKEym0pdaVRjGS06rbKaDFu9cxy1Bo7hh4V/9KHbmvnAt+oTQILF96lnPk DheQ== X-Gm-Message-State: AOAM532a0Qw0u8K5N07B8FK3inHbRu9Uuai+J3LadnjJxVRGR14GLtj7 kpubuoP5QDk/ZvuKmyQ0PcPp4+SXQj3NzFd5Z0oKwQ== 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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