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