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 5B8E3C41604 for ; Tue, 6 Oct 2020 12:27:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B9BF5206F7 for ; Tue, 6 Oct 2020 12:26:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="SN4g7TUI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B9BF5206F7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CA5E3900003; Tue, 6 Oct 2020 08:26:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C56D66B0071; Tue, 6 Oct 2020 08:26:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B1D76900003; Tue, 6 Oct 2020 08:26:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0047.hostedemail.com [216.40.44.47]) by kanga.kvack.org (Postfix) with ESMTP id 7E4CB6B0070 for ; Tue, 6 Oct 2020 08:26:58 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0770A2C93 for ; Tue, 6 Oct 2020 12:26:58 +0000 (UTC) X-FDA: 77341424916.22.trees82_0d0fdf9271c6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id CB13018038E60 for ; Tue, 6 Oct 2020 12:26:57 +0000 (UTC) X-HE-Tag: trees82_0d0fdf9271c6 X-Filterd-Recvd-Size: 5862 Received: from mail-qk1-f196.google.com (mail-qk1-f196.google.com [209.85.222.196]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Tue, 6 Oct 2020 12:26:57 +0000 (UTC) Received: by mail-qk1-f196.google.com with SMTP id s7so10450847qkh.11 for ; Tue, 06 Oct 2020 05:26:56 -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=QPkLFR7145e6QzM4ruw6wA3I0wFc9mxBmVr0O/3LBW4by2C+xqJBu2ljA5gB928xon 9VU0w8cXmERDFfvXgac9XFE828IIrDKSLk8U86OAG/wOhBFPN7QMKwqcyjx2LuViYeef yOhd4vsbQb7ChQePzZp6Dl78xM0ZfhnRd2LFXoxKwcOf9Zhn8HgcfE3BwB9rx/Ufbh2S PhykBH8ALnFTS0ocG9bpseg/RVyykzry2UA9QaVXf313AYQNB0yvGCUoGDSnMi2194Ce ZI7ct2hoxKSLn3/zKDgl2dTeFT4+4aAPgBg5tdEv/lEiJ0ga4dH9gzgtBHhLL52avXmS Rqhw== X-Gm-Message-State: AOAM5311OCwJpbTROKrlvRtlJTcT8cxbOFI14iiJGfkUPkKJ7jpRa8A3 2bBkJx9jGG2eP3gvp46WAqNzHQ== 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: 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 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