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=-5.7 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 58DC1C433DB for ; Fri, 5 Feb 2021 09:24:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 02EDC64FBF for ; Fri, 5 Feb 2021 09:24:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230050AbhBEJXq (ORCPT ); Fri, 5 Feb 2021 04:23:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229587AbhBEJPr (ORCPT ); Fri, 5 Feb 2021 04:15:47 -0500 Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66FE1C061793 for ; Fri, 5 Feb 2021 01:15:07 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id y199so4771685oia.4 for ; Fri, 05 Feb 2021 01:15:07 -0800 (PST) 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; bh=bXNMzkZKAQHAIrPBhbAfZJ1F8VP6J4t5+TSc68lOL4Y=; b=a+ji2SzyZm3n8vVEHzAMZc8QntIgLAYyHbAXu1DjdIj2YXSB95Kk9f0X7dpvSIMx4b ZOgF3PKpF755HKCdIJr6U5t6zLzDDh9y1RUPzOpqu9dSY2DlYKR39mapqWK/IkqzmmOQ jhaJmkwjl1dKvNndYYw0eyycjistU6FYnbvB0= 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; bh=bXNMzkZKAQHAIrPBhbAfZJ1F8VP6J4t5+TSc68lOL4Y=; b=emGJ2Zi716eHQ8u2U/na8ZMZhrhBj1up1ZVfM4l037jYgQV+wHeyc9akWsHnkHpojf UkD4iJfq2i96bxmHvmfn8Bd5vRP1SQ6nZy8pb4Z43skclzwZQ7VGuqHYM2AQLV6vpJI/ MmffLUJ2mgsqvIzTyIdwF3fNq7bDDxiK+24+8tM6KyFP7OeyNnAmt/d1OtrUEDzMyvZW 3IslELVC30YoKHvnEEAUUPSIM3n0CYD4rdL5NKr8HlTMZKKo+LwShu9Hup+xR5IAoCSM T/e5JnkTSU/zw+jT2k4za5P14zYilNvIUzZjP5O2OpWhUf6PT+Hk3ePMAJZ6MrNrZiRr sJEQ== X-Gm-Message-State: AOAM531Gr64fFxpCxBsMU1oF57hyaQyFqcaM1hxSqytopIHdEbF+6BDZ K94SKdG4woi7oRaxQgSoeh/xMJaiKhb38y3Yv9RYYw== X-Google-Smtp-Source: ABdhPJxEMaYu1JXRr4pq0v6xG4RV1wNpt4QeaMRtr7VxclNNU/6kd9mpU8CVuZPrSywCRKR/06lHELNic7Bm/GFyf1k= X-Received: by 2002:aca:df42:: with SMTP id w63mr2473363oig.128.1612516506743; Fri, 05 Feb 2021 01:15:06 -0800 (PST) MIME-Version: 1.0 References: <20210203211948.2529297-1-daniel.vetter@ffwll.ch> <20210204161339.GX4718@ziepe.ca> <20210204183808.GY4718@ziepe.ca> <20210204200918.GA4718@ziepe.ca> <20210204205927.GD4718@ziepe.ca> In-Reply-To: <20210204205927.GD4718@ziepe.ca> From: Daniel Vetter Date: Fri, 5 Feb 2021 10:14:55 +0100 Message-ID: Subject: Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap To: Jason Gunthorpe Cc: DRI Development , Intel Graphics Development , Suren Baghdasaryan , Matthew Wilcox , John Stultz , Daniel Vetter , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , "open list:DMA BUFFER SHARING FRAMEWORK" , "moderated list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Thu, Feb 4, 2021 at 9:59 PM Jason Gunthorpe wrote: > > On Thu, Feb 04, 2021 at 09:19:57PM +0100, Daniel Vetter wrote: > > On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe wrote: > > > > > > On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote: > > > > > > > So I think just checking for VM_PFNMAP after the vma is set up should > > > > be enough to guarantee we'll only have pte_special ptes in there, > > > > ever. But I'm not sure, this stuff all isn't really documented much > > > > and the code is sometimes a maze (to me at least). > > > > > > Yes, that makes sense. VM_PFNMAP and !VM_MIXEDMAP seems like the right > > > check after the VMA is populated > > > > > > But how do you stuff special pfns into a VMA outside the fault > > > handler? > > > > Many drivers we have don't have dynamic buffer management (kinda > > overkill for a few framebuffers on a display-only IP block), so the > > just remap_pfn_range on ->mmap, and don't have a fault handler at all. > > remap_pfn_range() makes sense, do you expect drivers using struct page > backed memory to call that as well? All the ones using CMA through dma_alloc_coherent end up in there with the dma_mmap_wc function. So yeah we have tons already. The drivers with dynamic memory management all use vm_insert_pfn, even when the buffer is in system memory and struct page backed. I think those are the two cases. There's another mmap in drm/i915, but that should never leave intel-specific userspace, and I think we're also phasing it out somewhat. Either way, should never show up in a shared buffer usecase, ever, so I think we can ignore it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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.5 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 EA0F9C433E0 for ; Fri, 5 Feb 2021 09:15:10 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 96BCB64F38 for ; Fri, 5 Feb 2021 09:15:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 96BCB64F38 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4C29F6E9A3; Fri, 5 Feb 2021 09:15:08 +0000 (UTC) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6CB0A6E9A3 for ; Fri, 5 Feb 2021 09:15:07 +0000 (UTC) Received: by mail-oi1-x229.google.com with SMTP id w8so6804537oie.2 for ; Fri, 05 Feb 2021 01:15:07 -0800 (PST) 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; bh=bXNMzkZKAQHAIrPBhbAfZJ1F8VP6J4t5+TSc68lOL4Y=; b=a+ji2SzyZm3n8vVEHzAMZc8QntIgLAYyHbAXu1DjdIj2YXSB95Kk9f0X7dpvSIMx4b ZOgF3PKpF755HKCdIJr6U5t6zLzDDh9y1RUPzOpqu9dSY2DlYKR39mapqWK/IkqzmmOQ jhaJmkwjl1dKvNndYYw0eyycjistU6FYnbvB0= 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; bh=bXNMzkZKAQHAIrPBhbAfZJ1F8VP6J4t5+TSc68lOL4Y=; b=mntRj7Onta6Rc72kIC0US2qp1MfeMXRFwn2nncXgghWmWcfyJtC7g0kCWfrZPt7hZe kI9yKrDi+aXxjZ8NPLFW9c8wZi+P6Xn/Q7PhW+XitYpJ8xu/zp1bpMPmhzdOpj1/lnGK HLnMr+4icFWcUb+f9UYgkSUHYq81UsGXDe9K+v54HXsWKp3W9NwCivKtNkpJ1T5JRLe9 cev94RN1jovjy38yey26bjRVxiIr+xCq15Db+zbFSloeuJOGmzKPWtpPC9Y92LSJDexY Z8HqULQoqfk8wdL5sRpDR3wwFcnTUj3P+S3QJdsmuwaKQgHdkTORoI3ePBO7D+4eSqSx Z4iA== X-Gm-Message-State: AOAM531NG+wKAUVsk6sZKdemuvcv48yMg0fYI69TJvFeRXE4/VUEYbqa 6A90P33nOY7144uH13COtMgIfNR/pTBreM0O+ol5MA== X-Google-Smtp-Source: ABdhPJxEMaYu1JXRr4pq0v6xG4RV1wNpt4QeaMRtr7VxclNNU/6kd9mpU8CVuZPrSywCRKR/06lHELNic7Bm/GFyf1k= X-Received: by 2002:aca:df42:: with SMTP id w63mr2473363oig.128.1612516506743; Fri, 05 Feb 2021 01:15:06 -0800 (PST) MIME-Version: 1.0 References: <20210203211948.2529297-1-daniel.vetter@ffwll.ch> <20210204161339.GX4718@ziepe.ca> <20210204183808.GY4718@ziepe.ca> <20210204200918.GA4718@ziepe.ca> <20210204205927.GD4718@ziepe.ca> In-Reply-To: <20210204205927.GD4718@ziepe.ca> From: Daniel Vetter Date: Fri, 5 Feb 2021 10:14:55 +0100 Message-ID: Subject: Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap To: Jason Gunthorpe X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Intel Graphics Development , Matthew Wilcox , =?UTF-8?Q?Christian_K=C3=B6nig?= , "moderated list:DMA BUFFER SHARING FRAMEWORK" , DRI Development , Daniel Vetter , Suren Baghdasaryan , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Feb 4, 2021 at 9:59 PM Jason Gunthorpe wrote: > > On Thu, Feb 04, 2021 at 09:19:57PM +0100, Daniel Vetter wrote: > > On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe wrote: > > > > > > On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote: > > > > > > > So I think just checking for VM_PFNMAP after the vma is set up should > > > > be enough to guarantee we'll only have pte_special ptes in there, > > > > ever. But I'm not sure, this stuff all isn't really documented much > > > > and the code is sometimes a maze (to me at least). > > > > > > Yes, that makes sense. VM_PFNMAP and !VM_MIXEDMAP seems like the right > > > check after the VMA is populated > > > > > > But how do you stuff special pfns into a VMA outside the fault > > > handler? > > > > Many drivers we have don't have dynamic buffer management (kinda > > overkill for a few framebuffers on a display-only IP block), so the > > just remap_pfn_range on ->mmap, and don't have a fault handler at all. > > remap_pfn_range() makes sense, do you expect drivers using struct page > backed memory to call that as well? All the ones using CMA through dma_alloc_coherent end up in there with the dma_mmap_wc function. So yeah we have tons already. The drivers with dynamic memory management all use vm_insert_pfn, even when the buffer is in system memory and struct page backed. I think those are the two cases. There's another mmap in drm/i915, but that should never leave intel-specific userspace, and I think we're also phasing it out somewhat. Either way, should never show up in a shared buffer usecase, ever, so I think we can ignore it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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.5 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 1B9C2C433DB for ; Fri, 5 Feb 2021 09:15:14 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BA7B064F70 for ; Fri, 5 Feb 2021 09:15:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA7B064F70 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E54146EB55; Fri, 5 Feb 2021 09:15:08 +0000 (UTC) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by gabe.freedesktop.org (Postfix) with ESMTPS id 726896E9B0 for ; Fri, 5 Feb 2021 09:15:07 +0000 (UTC) Received: by mail-oi1-x229.google.com with SMTP id k25so6734661oik.13 for ; Fri, 05 Feb 2021 01:15:07 -0800 (PST) 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; bh=bXNMzkZKAQHAIrPBhbAfZJ1F8VP6J4t5+TSc68lOL4Y=; b=a+ji2SzyZm3n8vVEHzAMZc8QntIgLAYyHbAXu1DjdIj2YXSB95Kk9f0X7dpvSIMx4b ZOgF3PKpF755HKCdIJr6U5t6zLzDDh9y1RUPzOpqu9dSY2DlYKR39mapqWK/IkqzmmOQ jhaJmkwjl1dKvNndYYw0eyycjistU6FYnbvB0= 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; bh=bXNMzkZKAQHAIrPBhbAfZJ1F8VP6J4t5+TSc68lOL4Y=; b=L3AeErepQBW7+ZklrIC+Yj5pnt4xOGGqdS1RhNYXyBbLDx5N41EaE3xPe9h2+Yh+2i 2WKxRLjY9JSRrDUhYYGWBMda6294msPQei7xLIdHGu6Sh/D6uqTBstjgudVQ3aEKy91Z qPGPrHgsJ3XAXqzOOslOLvTHWH/HfY1ClHDYsMZc0Qp+dLbKL3KTPZVF3R8hnqpdTkdv HaGLxFIGHAb7hybG/yR0sd3oaibS35hsLGOltGkFzBjyfADqDvDVyt3JPbnvubgYcKwI 5HV2ThcBcjOGoiwrsup/fpaxktmnrEynDoL/IL/xFgjlMJ/w4KAads9JD1ZWApNgSS7v FADQ== X-Gm-Message-State: AOAM530+9rigAg8ontKtx59FHD+PRuzmJ/Pu+o3EMH1eL7GS8Lki3EZ8 Pe7dwF4ZjjFRPKqKvMszo7G+C0Mo169mfmyy9WA1CQ== X-Google-Smtp-Source: ABdhPJxEMaYu1JXRr4pq0v6xG4RV1wNpt4QeaMRtr7VxclNNU/6kd9mpU8CVuZPrSywCRKR/06lHELNic7Bm/GFyf1k= X-Received: by 2002:aca:df42:: with SMTP id w63mr2473363oig.128.1612516506743; Fri, 05 Feb 2021 01:15:06 -0800 (PST) MIME-Version: 1.0 References: <20210203211948.2529297-1-daniel.vetter@ffwll.ch> <20210204161339.GX4718@ziepe.ca> <20210204183808.GY4718@ziepe.ca> <20210204200918.GA4718@ziepe.ca> <20210204205927.GD4718@ziepe.ca> In-Reply-To: <20210204205927.GD4718@ziepe.ca> From: Daniel Vetter Date: Fri, 5 Feb 2021 10:14:55 +0100 Message-ID: To: Jason Gunthorpe Subject: Re: [Intel-gfx] [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Intel Graphics Development , Matthew Wilcox , =?UTF-8?Q?Christian_K=C3=B6nig?= , "moderated list:DMA BUFFER SHARING FRAMEWORK" , John Stultz , DRI Development , Daniel Vetter , Suren Baghdasaryan , Sumit Semwal , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, Feb 4, 2021 at 9:59 PM Jason Gunthorpe wrote: > > On Thu, Feb 04, 2021 at 09:19:57PM +0100, Daniel Vetter wrote: > > On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe wrote: > > > > > > On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote: > > > > > > > So I think just checking for VM_PFNMAP after the vma is set up should > > > > be enough to guarantee we'll only have pte_special ptes in there, > > > > ever. But I'm not sure, this stuff all isn't really documented much > > > > and the code is sometimes a maze (to me at least). > > > > > > Yes, that makes sense. VM_PFNMAP and !VM_MIXEDMAP seems like the right > > > check after the VMA is populated > > > > > > But how do you stuff special pfns into a VMA outside the fault > > > handler? > > > > Many drivers we have don't have dynamic buffer management (kinda > > overkill for a few framebuffers on a display-only IP block), so the > > just remap_pfn_range on ->mmap, and don't have a fault handler at all. > > remap_pfn_range() makes sense, do you expect drivers using struct page > backed memory to call that as well? All the ones using CMA through dma_alloc_coherent end up in there with the dma_mmap_wc function. So yeah we have tons already. The drivers with dynamic memory management all use vm_insert_pfn, even when the buffer is in system memory and struct page backed. I think those are the two cases. There's another mmap in drm/i915, but that should never leave intel-specific userspace, and I think we're also phasing it out somewhat. Either way, should never show up in a shared buffer usecase, ever, so I think we can ignore it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx