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 4AFD0C4727F for ; Tue, 6 Oct 2020 06:23:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9371020796 for ; Tue, 6 Oct 2020 06:23:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="CT82R/qJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9371020796 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 95F0F8E0001; Tue, 6 Oct 2020 02:23:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 90E026B005D; Tue, 6 Oct 2020 02:23:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D5D18E0001; Tue, 6 Oct 2020 02:23:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0067.hostedemail.com [216.40.44.67]) by kanga.kvack.org (Postfix) with ESMTP id 505656B005C for ; Tue, 6 Oct 2020 02:23:37 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A03918249980 for ; Tue, 6 Oct 2020 06:23:36 +0000 (UTC) X-FDA: 77340509232.15.plate23_1200a5c271c4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 76ED31814B0C1 for ; Tue, 6 Oct 2020 06:23:36 +0000 (UTC) X-HE-Tag: plate23_1200a5c271c4 X-Filterd-Recvd-Size: 5537 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Tue, 6 Oct 2020 06:23:35 +0000 (UTC) Received: by mail-oi1-f194.google.com with SMTP id u17so5280647oie.3 for ; Mon, 05 Oct 2020 23:23:35 -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=VlNmxwIhwcXv4qHaxqexSUmm4G1xHiiGF3qHpNL5GMg=; b=CT82R/qJcvEDDvUxaCuGu0crYHNtAwxAMVNAs/kuENoPD7ejHIrOjRRYZ5Z8oCc426 9TSBbW807u/3VmVRvKsdS89xhG0WR+iBlXlWazslsVcZWyIlBUEZBJcv6Cup8NE4NVEO ylxmZFFhoOkflOBJvGoBFOXFntWaDWJ4rVAUI= 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=VlNmxwIhwcXv4qHaxqexSUmm4G1xHiiGF3qHpNL5GMg=; b=mJxwrh6AphSZog4z0L4TQHFa+kw+26FkLMjL2Eukh46NmZgQEP9OdV/lwhMuufEOtM q7Zu5L21vrYniwUImGiOeSCeQ3/IfCdJ87hmJ7bCsoEcWqKilw0C7NzVSyX+/FwevhMU yEwDPBrsF5STkBfwpp0ROdK4xC+h3nABLzkc1QD5uIb1YxlwmAggxC8gcxrxsKTrXL5z MRdRRoXr6j8puqeTs5lYcB2YVffvyEPtb0vE1ANHAllsCQevI50eldZARudeXQil2I2W BqRqXgCtJBbh1Gmv/gJrqn7dt07fmrQcE0j9ZstnSLGIK+hFg5R6ea/eR7r3+cItkCn7 6lnQ== X-Gm-Message-State: AOAM532nThn2CLKSzwMCm1PeT+m1CXO6cY8SFCMbc7Qs2Q/KSI4f7zPC i2qe4oLVZlt3ZMMKPi0c/9tll8muenRKsn5gn5040g== X-Google-Smtp-Source: ABdhPJwng0gDkXMKOpdZZMK3MDpDIZD7O95qBIJyXqDkv8t4rKoM6Kv3eRzC/BlAMFJrRN/Z/vlIq1gJtQeg5R2bqC0= X-Received: by 2002:a05:6808:206:: with SMTP id l6mr1854734oie.128.1601965414834; Mon, 05 Oct 2020 23:23:34 -0700 (PDT) MIME-Version: 1.0 References: <20201002233118.GM9916@ziepe.ca> <20201004125059.GP9916@ziepe.ca> <20201005172854.GA5177@ziepe.ca> <20201005183704.GC5177@ziepe.ca> <20201005234104.GD5177@ziepe.ca> In-Reply-To: <20201005234104.GD5177@ziepe.ca> From: Daniel Vetter Date: Tue, 6 Oct 2020 08:23:23 +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 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. But when you use cma as the contig allocator (mostly with dma_alloc_coherent) and then remap that for userspace (e.g. dma_mmap_wc), then anyone doing pup or gup should not try to migrate anything. Also in the past these contig ranges where generally carveouts without any struct page, changing that would break too much I guess. > > Plus trying to move the cma pages out of cma for FOLL_LONGTERM would > > be kinda bad when they've been allocated as a contig block by > > dma_alloc_coherent :-) > > Isn't holding a long term reference to a CMA page one of those really > scary use-after-free security issues I've been talking about? > > I know nothing about CMA, so can't say too much, sorry Uh ... yes :-/ 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 :-( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch