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 66F6AC4727E for ; Tue, 6 Oct 2020 12:27:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 21DC120789 for ; Tue, 6 Oct 2020 12:27:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="SN4g7TUI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726460AbgJFM07 (ORCPT ); Tue, 6 Oct 2020 08:26:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726386AbgJFM06 (ORCPT ); Tue, 6 Oct 2020 08:26:58 -0400 Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40B52C0613D1 for ; Tue, 6 Oct 2020 05:26:57 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id c62so16400235qke.1 for ; Tue, 06 Oct 2020 05:26:57 -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:in-reply-to; bh=xBjl3ijOtmAZHKFY2Q8VHDVWCHXszRzYVrHWQVZx7Tk=; b=SN4g7TUIcZiG8gkjZ1H/2y7nSkf/356q8TN46sZv42cMGw257ggPHqEIxcAVaP+JLI 3COaYblkwqSkvZ3VvGo2aUITxO8n/evEej4R7WiuDd7vx54iTJcM3rODUcbY6fWaVTW4 EVA/uoMKZADbRpGktJwSEyKjfdPmW4OZ5Pgj9gbyiUAeVG9BSCNrYKIVLMh5QYABE1hs w1jTd6DwqzNWx+JVVeImewGQMVDM8zVSKQkPPfvZMzsDUJL1mfqV3Q9BDqZ118Hyt26G gkZ1HAOD9Z0OMFKclpgVIarkGX2NI41znNb9Xowm3HI01KbpOjvjgZDdADe5bWIp/JNN qaaQ== 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:in-reply-to; bh=xBjl3ijOtmAZHKFY2Q8VHDVWCHXszRzYVrHWQVZx7Tk=; b=ecQBx0sGNmEQu/vOW+drNdggDoctpvnlTv+C0G4QQKbys3ETMJL2+4SajmZGHI1wcM +sPRMfjmRDEHqGO44BVJWphYOHpWZ8oKl0eF4jbDS1Lni+5NKjFiJJqlEzzHjyXwmcTk DfVNI+ZNgvJ3/7NHH4yZCRZHiDahRdaQUEFjlWZDyvtQvAsu5+AR76A6Fy/BggfO+Eo5 L/qujcxNoTfwzNhtI4Yiz3difBQgucnqPDADhOj7LkcYGwBTdeGkpsWMbkZsiHqQojUX AhvIHZuFn3108TR627+2NS3fN6shfmPna5t+dI9WuSSSsPIaIZeBdYsTR4U+Q2d26usI sxuw== X-Gm-Message-State: AOAM533aCPIJaFwJXikRUQR8Kad53UKJCE7B1HqFzvbJ6UqVOR94uuLi AT8J4odWNg0Te4AqZxvlj8sm7Q== X-Google-Smtp-Source: ABdhPJw5uBK6Jg1qFL06jjeM7TFRlowFnJJ0b29ROqLVECyy9T+v9Aj67lt6n4PC1ZTOH3f53Rrkvg== X-Received: by 2002:a37:2c06:: with SMTP id s6mr4947152qkh.55.1601987216328; Tue, 06 Oct 2020 05:26:56 -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 m67sm2358458qkf.98.2020.10.06.05.26.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2020 05:26:55 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kPm3T-000W9Y-2O; Tue, 06 Oct 2020 09:26:55 -0300 Date: Tue, 6 Oct 2020 09:26:55 -0300 From: Jason Gunthorpe To: Daniel Vetter Cc: DRI Development , LKML , Daniel Vetter , Andrew Morton , John Hubbard , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Jan Kara , Dan Williams , Linux MM , Linux ARM , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Tomasz Figa , Inki Dae , Joonyoung Shim , Seung-Woo Kim , linux-samsung-soc , "open list:DMA BUFFER SHARING FRAMEWORK" , Oded Gabbay Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Message-ID: <20201006122655.GG5177@ziepe.ca> References: <20201004125059.GP9916@ziepe.ca> <20201005172854.GA5177@ziepe.ca> <20201005183704.GC5177@ziepe.ca> <20201005234104.GD5177@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 06, 2020 at 08:23:23AM +0200, Daniel Vetter wrote: > On Tue, Oct 6, 2020 at 1:41 AM Jason Gunthorpe wrote: > > > > On Tue, Oct 06, 2020 at 12:43:31AM +0200, Daniel Vetter wrote: > > > > > > iow I think I can outright delete the frame vector stuff. > > > > > > Ok this doesn't work, because dma_mmap always uses a remap_pfn_range, > > > which is a VM_IO | VM_PFNMAP vma and so even if it's cma backed and > > > not a carveout, we can't get the pages. > > > > If CMA memory has struct pages it probably should be mmap'd with > > different flags, and the lifecycle of the CMA memory needs to respect > > the struct page refcount? > > I guess yes and no. The problem is if there's pagecache in the cma > region, pup(FOLL_LONGTERM) needs to first migrate those pages out of > the cma range. Because all normal page allocation in cma regions must > be migratable at all times. Eh? Then how are we doing follow_pfn() on this stuff and not being completely broken? The entire point of this framevec API is to pin the memory and preventing it from moving around. Sounds like it is fundamentally incompatible with CMA. Why is something trying to mix the two? > This is actually worse than the gpu case I had in mind, where at most > you can sneak access other gpu buffers. With cma you should be able to > get at arbitrary pagecache (well anything that's GFP_MOVEABLE really). > Nice :-( Ah, we have a winner :\ Jason 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=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 47643C4363D for ; Tue, 6 Oct 2020 12:28:47 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 AFC85206F7 for ; Tue, 6 Oct 2020 12:28:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mkijK6kl"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="SN4g7TUI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AFC85206F7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=nAGlDNF0MdyKqEuA0MMdnTY/csUAs2USw6U393p4hLA=; b=mkijK6klX6fQIGGfNxMAY9g2m fXoc2qpEaTVw+iwA50aAfSbGkGrSrVfrQJTzZVlXFjJe0psJHMnnMgFRPS02jvN0Syhvd7uo1UyUV +uREGtHGJk/KALPwL6HmyurgvpUzubc+JCs+I7gXqoEldJoHkoZFAUV9nB4FL31/d7/iJVQFfTM6w nygSRdVTGDMs/5207QYzsA9l+0c74bzzTxMQis3WsDw6MzM0kkeGxJs989G/3XMWvHaxQ83UaKaQT 93TvgFjgGVCw8WDkObQUB4mzCnwTvCgfCY47tYL+2qh0h2jOOC+e/buX36hcIsBKAaotimuJ7O34l 5F7go5YPg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPm3Z-0001NZ-CH; Tue, 06 Oct 2020 12:27:01 +0000 Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPm3W-0001Ml-7e for linux-arm-kernel@lists.infradead.org; Tue, 06 Oct 2020 12:26:58 +0000 Received: by mail-qk1-x744.google.com with SMTP id q5so16395200qkc.2 for ; Tue, 06 Oct 2020 05:26:57 -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:in-reply-to; bh=xBjl3ijOtmAZHKFY2Q8VHDVWCHXszRzYVrHWQVZx7Tk=; b=SN4g7TUIcZiG8gkjZ1H/2y7nSkf/356q8TN46sZv42cMGw257ggPHqEIxcAVaP+JLI 3COaYblkwqSkvZ3VvGo2aUITxO8n/evEej4R7WiuDd7vx54iTJcM3rODUcbY6fWaVTW4 EVA/uoMKZADbRpGktJwSEyKjfdPmW4OZ5Pgj9gbyiUAeVG9BSCNrYKIVLMh5QYABE1hs w1jTd6DwqzNWx+JVVeImewGQMVDM8zVSKQkPPfvZMzsDUJL1mfqV3Q9BDqZ118Hyt26G gkZ1HAOD9Z0OMFKclpgVIarkGX2NI41znNb9Xowm3HI01KbpOjvjgZDdADe5bWIp/JNN qaaQ== 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:in-reply-to; bh=xBjl3ijOtmAZHKFY2Q8VHDVWCHXszRzYVrHWQVZx7Tk=; b=KVzMC+gbLzCN2/IIkDnrnGJLmGEAWV+/pwGEWl8jmkCl7592xcTUljHbmkeWh8/OiH dPQKKwzOt4sDeWYnuimqdMPAYMpttACPFOoIQ+aWzZ/pY1y+PGOD5W1oBJ2dsQ3YIrcj yZrJd4fRow6ROZmD+W0N491tqnMofXi7zrTRrGY2ueN+LOHVxdD0SGrpNQD5GxfEP+82 eEOOqDOSXoAPVrcyMrH71xU9citHknwRsEKOkkZJgzudHBKIMm3WH9QmTX0PHyDQk6gr 3pJU8WO/vkFdkVQ5TmBSbQ0VRO7KtlcKci4TFa8bfePL//yRmkon0ZMTzZhh+VpzChUS tF5A== X-Gm-Message-State: AOAM531UaFuAPruygEnxqFLEwunozzC8mrp4wbiE6CPhPM66Z2OP/B7R sWavM+GugxjmHhrHrzh9VHr/3g== X-Google-Smtp-Source: ABdhPJw5uBK6Jg1qFL06jjeM7TFRlowFnJJ0b29ROqLVECyy9T+v9Aj67lt6n4PC1ZTOH3f53Rrkvg== X-Received: by 2002:a37:2c06:: with SMTP id s6mr4947152qkh.55.1601987216328; Tue, 06 Oct 2020 05:26:56 -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 m67sm2358458qkf.98.2020.10.06.05.26.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2020 05:26:55 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kPm3T-000W9Y-2O; Tue, 06 Oct 2020 09:26:55 -0300 Date: Tue, 6 Oct 2020 09:26:55 -0300 From: Jason Gunthorpe To: Daniel Vetter Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Message-ID: <20201006122655.GG5177@ziepe.ca> References: <20201004125059.GP9916@ziepe.ca> <20201005172854.GA5177@ziepe.ca> <20201005183704.GC5177@ziepe.ca> <20201005234104.GD5177@ziepe.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201006_082658_290577_3DBE3E40 X-CRM114-Status: GOOD ( 20.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Oded Gabbay , Inki Dae , linux-samsung-soc , Jan Kara , Joonyoung Shim , Pawel Osciak , John Hubbard , Seung-Woo Kim , LKML , DRI Development , Tomasz Figa , Kyungmin Park , Linux MM , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Daniel Vetter , Andrew Morton , "open list:DMA BUFFER SHARING FRAMEWORK" , Dan Williams , Linux ARM , Marek Szyprowski Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Oct 06, 2020 at 08:23:23AM +0200, Daniel Vetter wrote: > On Tue, Oct 6, 2020 at 1:41 AM Jason Gunthorpe wrote: > > > > On Tue, Oct 06, 2020 at 12:43:31AM +0200, Daniel Vetter wrote: > > > > > > iow I think I can outright delete the frame vector stuff. > > > > > > Ok this doesn't work, because dma_mmap always uses a remap_pfn_range, > > > which is a VM_IO | VM_PFNMAP vma and so even if it's cma backed and > > > not a carveout, we can't get the pages. > > > > If CMA memory has struct pages it probably should be mmap'd with > > different flags, and the lifecycle of the CMA memory needs to respect > > the struct page refcount? > > I guess yes and no. The problem is if there's pagecache in the cma > region, pup(FOLL_LONGTERM) needs to first migrate those pages out of > the cma range. Because all normal page allocation in cma regions must > be migratable at all times. Eh? Then how are we doing follow_pfn() on this stuff and not being completely broken? The entire point of this framevec API is to pin the memory and preventing it from moving around. Sounds like it is fundamentally incompatible with CMA. Why is something trying to mix the two? > This is actually worse than the gpu case I had in mind, where at most > you can sneak access other gpu buffers. With cma you should be able to > get at arbitrary pagecache (well anything that's GFP_MOVEABLE really). > Nice :-( Ah, we have a winner :\ Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 274FFC4727E for ; Wed, 7 Oct 2020 07:22:58 +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 A8947207EA for ; Wed, 7 Oct 2020 07:22:57 +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="SN4g7TUI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A8947207EA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca 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 1BC096E03F; Wed, 7 Oct 2020 07:22:34 +0000 (UTC) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by gabe.freedesktop.org (Postfix) with ESMTPS id 38E986E456 for ; Tue, 6 Oct 2020 12:26:57 +0000 (UTC) Received: by mail-qk1-x744.google.com with SMTP id z6so7858784qkz.4 for ; Tue, 06 Oct 2020 05:26:57 -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:in-reply-to; bh=xBjl3ijOtmAZHKFY2Q8VHDVWCHXszRzYVrHWQVZx7Tk=; b=SN4g7TUIcZiG8gkjZ1H/2y7nSkf/356q8TN46sZv42cMGw257ggPHqEIxcAVaP+JLI 3COaYblkwqSkvZ3VvGo2aUITxO8n/evEej4R7WiuDd7vx54iTJcM3rODUcbY6fWaVTW4 EVA/uoMKZADbRpGktJwSEyKjfdPmW4OZ5Pgj9gbyiUAeVG9BSCNrYKIVLMh5QYABE1hs w1jTd6DwqzNWx+JVVeImewGQMVDM8zVSKQkPPfvZMzsDUJL1mfqV3Q9BDqZ118Hyt26G gkZ1HAOD9Z0OMFKclpgVIarkGX2NI41znNb9Xowm3HI01KbpOjvjgZDdADe5bWIp/JNN qaaQ== 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:in-reply-to; bh=xBjl3ijOtmAZHKFY2Q8VHDVWCHXszRzYVrHWQVZx7Tk=; b=iOd2u27ayxlI4OYet2llrR0QiVhfzqUPmKf6a+wTrSnp5i1ysE63uNbGXTGD/tf61J ToUz58OkjRG28SPSnU60a9y9KSIFx23gX/eRmBpXfIutJqkuoSwt3+uUdo68HgfD/PmV J0tlpCF1G4m++pARJGGiu0nvJHKw68bJny3HIw+ETBjMNZq0l9KYk5JN9gPUheJcSnvn UGrmlpBoHf7P6DHzWM2eobzOboGklmJxDkXPNljRC8PpXZppBWZVtvrpA+c81BHQbLS9 n30TlghJbCsGZZ8KgXvMZKKpUl6RJsl4XF2QOr93Q2AKRB6s1l6aRFXuFjMN6SZQgf36 81lQ== X-Gm-Message-State: AOAM530nnV+UHZCMgB9HuO4F+k4SeYWVwf6sweePVpQGarWnkzyTKDsD rrOsZ4p9t8siZ5VPT6HkWF/bbg== X-Google-Smtp-Source: ABdhPJw5uBK6Jg1qFL06jjeM7TFRlowFnJJ0b29ROqLVECyy9T+v9Aj67lt6n4PC1ZTOH3f53Rrkvg== X-Received: by 2002:a37:2c06:: with SMTP id s6mr4947152qkh.55.1601987216328; Tue, 06 Oct 2020 05:26:56 -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 m67sm2358458qkf.98.2020.10.06.05.26.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2020 05:26:55 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kPm3T-000W9Y-2O; Tue, 06 Oct 2020 09:26:55 -0300 Date: Tue, 6 Oct 2020 09:26:55 -0300 From: Jason Gunthorpe To: Daniel Vetter Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Message-ID: <20201006122655.GG5177@ziepe.ca> References: <20201004125059.GP9916@ziepe.ca> <20201005172854.GA5177@ziepe.ca> <20201005183704.GC5177@ziepe.ca> <20201005234104.GD5177@ziepe.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Wed, 07 Oct 2020 07:22:33 +0000 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: linux-samsung-soc , Jan Kara , Joonyoung Shim , Pawel Osciak , John Hubbard , Seung-Woo Kim , LKML , DRI Development , Tomasz Figa , Kyungmin Park , Linux MM , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Daniel Vetter , Andrew Morton , "open list:DMA BUFFER SHARING FRAMEWORK" , Dan Williams , Linux ARM , Marek Szyprowski Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Oct 06, 2020 at 08:23:23AM +0200, Daniel Vetter wrote: > On Tue, Oct 6, 2020 at 1:41 AM Jason Gunthorpe wrote: > > > > On Tue, Oct 06, 2020 at 12:43:31AM +0200, Daniel Vetter wrote: > > > > > > iow I think I can outright delete the frame vector stuff. > > > > > > Ok this doesn't work, because dma_mmap always uses a remap_pfn_range, > > > which is a VM_IO | VM_PFNMAP vma and so even if it's cma backed and > > > not a carveout, we can't get the pages. > > > > If CMA memory has struct pages it probably should be mmap'd with > > different flags, and the lifecycle of the CMA memory needs to respect > > the struct page refcount? > > I guess yes and no. The problem is if there's pagecache in the cma > region, pup(FOLL_LONGTERM) needs to first migrate those pages out of > the cma range. Because all normal page allocation in cma regions must > be migratable at all times. Eh? Then how are we doing follow_pfn() on this stuff and not being completely broken? The entire point of this framevec API is to pin the memory and preventing it from moving around. Sounds like it is fundamentally incompatible with CMA. Why is something trying to mix the two? > This is actually worse than the gpu case I had in mind, where at most > you can sneak access other gpu buffers. With cma you should be able to > get at arbitrary pagecache (well anything that's GFP_MOVEABLE really). > Nice :-( Ah, we have a winner :\ Jason _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel