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 8295BC4363D for ; Tue, 6 Oct 2020 13:09:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CD75920782 for ; Tue, 6 Oct 2020 13:09:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="LIcR3mxl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CD75920782 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E5BB46B005C; Tue, 6 Oct 2020 09:09:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E33656B005D; Tue, 6 Oct 2020 09:09:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D496F6B0062; Tue, 6 Oct 2020 09:09:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0006.hostedemail.com [216.40.44.6]) by kanga.kvack.org (Postfix) with ESMTP id A80C86B005C for ; Tue, 6 Oct 2020 09:09:18 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 153563624 for ; Tue, 6 Oct 2020 13:09:18 +0000 (UTC) X-FDA: 77341531596.12.songs30_0714602271c6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 667411801F0F6 for ; Tue, 6 Oct 2020 13:09:03 +0000 (UTC) X-HE-Tag: songs30_0714602271c6 X-Filterd-Recvd-Size: 6520 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Tue, 6 Oct 2020 13:09:02 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id m13so12204516otl.9 for ; Tue, 06 Oct 2020 06:09:02 -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; bh=UIz7Ad1d8jfXlfMTcB0ZtI9qf0HUQ6fuKIJszWhIC+E=; b=LIcR3mxlTUwN2cQS3JOV9OT3XWZSqNM8o2MXOXJGnXBlTjosIunp2xH+4xIx4TFcmX bz9ZNBvOE+IWnnYFj2cRXRANjLRbYjiHsrPwgqT5Esz03Yaa5NJcAVZ84y6FBycdg5nl 9BP1OZjIaAgLdnUyieEXrQHDpl2wkajyftiXI= 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=UIz7Ad1d8jfXlfMTcB0ZtI9qf0HUQ6fuKIJszWhIC+E=; b=pnRZM9EAmdOFkYPca6XPz9ivjgZkKlDBbrfZEqYlT1VntkVH3cR5OM8qeQsQ8hX6vm RwbXzn+P7GqIF/KjeW02vwwMArEoOAD/kwlRQi7SMlhcmLnoCOieT2beODTsvTUz94ii nIVWbjvgCtHE0SOrlZI295hDc8s/DBYTNvSeHXEh28NELC8fBnjYePSMfOmd/N84nkey yS4TettizkQfqPIMNQwXu6NuR3yTUD0j46sque5CGyQrAA9zvkTJU3IvazTPNSOLaEjO kgqG690WStzJNwKlKES5jdQoK5gGvYRfJzMvJyXiGJRcG+618yTcs5mC26sa9C6YrwSv Y8xQ== X-Gm-Message-State: AOAM530EEEprSjkk4YYmRRX+entFOf0yAhPt7m3pZGT4/H7qjBAhamWb fDHtV+SpsvyhOPKpJBELwcTOomyM0xnNPAcPgJxUWQ== X-Google-Smtp-Source: ABdhPJzw1inwN+t+5foZtK0ezcoJPSOeTr206jyI3Yd7SrQuqlq6reZ+PEoA/n663vRpZhATnphV37mf6s0WcQ5NNFs= X-Received: by 2002:a05:6830:1647:: with SMTP id h7mr2992253otr.281.1601989741473; Tue, 06 Oct 2020 06:09:01 -0700 (PDT) MIME-Version: 1.0 References: <20201004125059.GP9916@ziepe.ca> <20201005172854.GA5177@ziepe.ca> <20201005183704.GC5177@ziepe.ca> <20201005234104.GD5177@ziepe.ca> <20201006122655.GG5177@ziepe.ca> In-Reply-To: <20201006122655.GG5177@ziepe.ca> From: Daniel Vetter Date: Tue, 6 Oct 2020 15:08:50 +0200 Message-ID: Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM To: Jason Gunthorpe Cc: DRI Development , LKML , Daniel Vetter , Andrew Morton , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , 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 Content-Type: text/plain; charset="UTF-8" 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 6, 2020 at 2:26 PM Jason Gunthorpe wrote: > > 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? I think the assumption way back when this started is that any VM_IO | VM_PFNMAP vma is perma-pinned because it's just a piece of carveout. Of course this ignored that it could also be a piece of iomem and peer2peer dma doens't Just Work, so could result in all kinds of hilarity and hw exceptions. But no leaks. Well, if you assume that the ownership of a device never changes after you've booted the system. But now we have dynamic gpu memory management, a bunch of subsystems that fully support revoke semantics (in a subsystem specific way), and CMA trying really hard to make the old carveouts useable for the system at large when the memory isn't needed by the device. So all these assumptions behind follow_pfn are out of the window, and follow_pfn is pretty much broken. What's worse I noticed that even for static pfnmaps (for userspace drivers) we now revoke access to those mmaps. For example implemented for /dev/mem in 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the region"). Which means follow_pfn isn't even working correctly anymore for that case, and it's all pretty much broken. > > 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 :\ Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch