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 CE23CC4727E for ; Tue, 6 Oct 2020 06:23:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 90728206DD 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" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727033AbgJFGXh (ORCPT ); Tue, 6 Oct 2020 02:23:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726944AbgJFGXh (ORCPT ); Tue, 6 Oct 2020 02:23:37 -0400 Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C47FC0613A7 for ; Mon, 5 Oct 2020 23:23:35 -0700 (PDT) Received: by mail-oi1-x241.google.com with SMTP id c13so11468109oiy.6 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=XcwVk/jQH+gem1sJglXRlQSXit3oXDS1O1BP8mEFYwkMUwT/drS50MCHBKZyJ3I1NA x/TPwpHdUfLDxz0787CD1WcawVB6ZjXu0lWuIZWQCad2MI1WdKBt+AipnPYfl4rjnNsI Xpf3VPuypbEoUhkiymdkYsGv4BJedt3iQNPw4ahK6OeLpa+ob9d/lZMpB1QuBoQNf+pg UDW/HAa7qZRudjGKRbT/G93PAZndaH3Y/q391x5ni1WIZltyRRQUmfzXC3y0DGVdZ4I2 m/sqLRS/g82v2LY0BAanp/49ybXp95KVSk+KYrwnzU9M/I6iXsaKS+W1ZxuRV++qTIzy q9gQ== X-Gm-Message-State: AOAM5308FEMh9RolhrTxaYM2upc1PUYnAJcsqJA0lDOQU4JLCdrq6EN0 jnvk8AjQPZtwxr6Rrhbh3Ukajhv7UBieMnSJ6TZnJQ== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 8AE92C41604 for ; Tue, 6 Oct 2020 06:25:13 +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 2F0ED206DD for ; Tue, 6 Oct 2020 06:25:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="sTmZavgc"; dkim=fail reason="signature verification failed" (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 2F0ED206DD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2YQfngEd6EvW6o4UpgUUe3FZgG9tx8DWT7qFKCjgokI=; b=sTmZavgcHoUxEaXN2/L+Bsot3 14hCwk2Qicse3j7CCm+Qlb2hIfUMCG/4ybAFVNLbbgoPvHqQ5Olg4wb2v391expYp81Z2gGxlBDtI LL4FGizVLXvCs11YLgYn7PiWRCIPiLYwyKAmRjJxKQKCuxNPYz9JotK16pJ/57KJNX6Z3vnuPVPOo bV4pIB89cgdrP7TTRovICNqRiB4PioHkbKVwxCjvt3L+AiaIUpkV4cQaeMebWCKNb86QrxQsP0JGZ T8YAYZcCfcSSWtZAAgYEm1ALvCk3tkeLOuUyvsDhmi5rkna49eRu3ngCD0hCDDN7mHOQyQnrVq2Pw at9kaaC/A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPgO0-0007VD-J6; Tue, 06 Oct 2020 06:23:44 +0000 Received: from mail-oi1-x243.google.com ([2607:f8b0:4864:20::243]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPgNw-0007SR-0H for linux-arm-kernel@lists.infradead.org; Tue, 06 Oct 2020 06:23:42 +0000 Received: by mail-oi1-x243.google.com with SMTP id n2so11474312oij.1 for ; Mon, 05 Oct 2020 23:23:36 -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=J+YV8HmSozWEekFISGa9HzbIzin6+BNVzQCNKaDYOHpbZINDN/T4DdEqG0xlisrd9/ a5Jzfo6pPlr+eOEmzMRpoxcS2LBaii9or9dLUrkv+X1Af+girwmd/Z/ab+/noIuxvYyX WZ0ZhHIcnT4mymhtK1lUeXYxo5IuaI31b/RX48liK8ntObc3AoAr7t5ZxOQZQdRmqXfv 3aiGp40F4wLEX1K7FcRJfKRgkg/SPPHujz4CzEcVRg7SM7iQucmupY16HqWzZTIh8P6V 4ZeNL/eQ5E8y8ZDHWMKZUouJ5qSnb9fvS1yojhw7AgdDeNXceh0LvVYfbSyxRVx1ZADE v9NQ== X-Gm-Message-State: AOAM531U15iD5FN3v5yznjzSgqoT3KYk91qKNL1l2OjT6kRNBWk/ynHR IruFjD2J1xxUwCwg81bBHSoE41O8u3BvcsDiZS/AGQ== 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201006_022340_090643_9C1619D5 X-CRM114-Status: GOOD ( 20.44 ) 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?SsOpcsO0bWUgR2xpc3Nl?= , 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 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 _______________________________________________ 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 50467C46466 for ; Tue, 6 Oct 2020 06:23:38 +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 422BB207EA for ; Tue, 6 Oct 2020 06:23:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (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 422BB207EA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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 91C2A6E122; Tue, 6 Oct 2020 06:23:36 +0000 (UTC) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) by gabe.freedesktop.org (Postfix) with ESMTPS id 953846E122 for ; Tue, 6 Oct 2020 06:23:35 +0000 (UTC) Received: by mail-oi1-x242.google.com with SMTP id u126so11436349oif.13 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=En2cUZ8BQAfiwQQMjd7blbXEl+MSakOlTJad778GOJqRagupjUqxHSb2++aHwzGh5f uHXIlNhGQr4E9jeUFUDMLTRWjQnyzGOTOWH7QpJ9bNdNYKOR3rFfsSrX6feVDpDD+vpv d3xFZDEPMLxebhniud4hhPbfEJW/UDZ+cwTGELKuRv6dPDtpFU9LTP9p0eV7ZRCRwTPp WQh3+3+EloyaEoMpeIw8WGE+GeaSQQEq+nN+L3RBndLJFQoVYXNnzZFuLOpWmhbrwYzT iPVJtRKYHKLh1c5QFh16AF49FY43sWhHSsUsJm16eq4HiEU4BjGzMS8rpuwfd+mKaHcu TkyQ== X-Gm-Message-State: AOAM530XE2cRj0ndI72swipaVVLuSZPOVuEhPQbhMrHieOcs0pRUgX2N iJ11taZTUAiuAiF7Yed/byN26a+gDx3kuQQvSUiarQ== 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 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?SsOpcsO0bWUgR2xpc3Nl?= , 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 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel