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 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 70E20C4363A for ; Mon, 5 Oct 2020 23:41:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 32746206CB for ; Mon, 5 Oct 2020 23:41:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="WQTRkabU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727162AbgJEXlK (ORCPT ); Mon, 5 Oct 2020 19:41:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40018 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725947AbgJEXlI (ORCPT ); Mon, 5 Oct 2020 19:41:08 -0400 Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 063C5C0613A7 for ; Mon, 5 Oct 2020 16:41:06 -0700 (PDT) Received: by mail-qv1-xf43.google.com with SMTP id ef16so7043771qvb.8 for ; Mon, 05 Oct 2020 16:41:06 -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=leFIXUGGn9SrvRUt+tSmZlGo2xUCkAybN0CLyh7hEVg=; b=WQTRkabULDUNXgUOMkqWCf8k/DuyDViVSLHiUwqLBS7jFU4O4kB9U8Yezw3zLkcX+0 N74emMID/Nf/tIrzUG3xn5IudsmLDLLSfJSFNjC86EZW2YCNxrAJ6Va1u5MyccDsjLiF PgIrU2vJ9V3he09nNerOKw2ijrvUXY3LxxxlUgWu78keT9R0r1XG2jEorE9lghUJYBq0 HDLVZIOGBufu8D7pIs8xJwLhuITDMBS+p/adlJyEPM0KYtmP3MPKnG7vX+ZYICLgx/+H 9Y3UojthIzYzht7NXCY0SCY8mLxjKGEXcgRu9Wjs6CR48TRqBN9ftH6xE+L/pIZNkLOu J6cA== 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=leFIXUGGn9SrvRUt+tSmZlGo2xUCkAybN0CLyh7hEVg=; b=NKiVu6r7Pm2aCsGeC3Reh08NPCdtSJ8XlGPiwFr9ZMG9wXRPT27nOdPXocnLmQkPia Rc8VtptfLr3Ti6VtPgVaz4yInqWmSSRzhqx937pUjT80MHdy5ZWdaiM2eYwwo3+zLcVs kimscHn6HqDyGUB8xVGrMFiCI4sgeBEm5L/iRvy+b9U4H6EWL8U9+K1QLN48vmco9Y2l Fc43HVlxKY8uQBDz3hHZY5aCWOAg6NSL819smrJxaOk7FqdBmqMPqqxBPKZIkGjygr9D xJE+kIqnvKB1CHV9/wCyHrnHpgcrolRitRMMAI4GlcN3Gp44AB8S2bk4tBkW2PWYjDTV xngw== X-Gm-Message-State: AOAM532kV/Mo+mqeG1+xRNn+MM6MBcbmOixJ7MjmIns/InaSQ7QnOs0S SsQJaWoL2Ej542sHjQeltHmbSg== X-Google-Smtp-Source: ABdhPJyH6Hj9DkTwkBpIGRlKmZqLkjKrSkdKR0kLJjsKJY55CJeobeIMUeExf41YR/ICDJqmfiJ9Hw== X-Received: by 2002:a05:6214:136f:: with SMTP id c15mr2074483qvw.57.1601941266028; Mon, 05 Oct 2020 16:41:06 -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 v30sm1069485qtj.52.2020.10.05.16.41.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2020 16:41:05 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kPa6K-000DCJ-94; Mon, 05 Oct 2020 20:41:04 -0300 Date: Mon, 5 Oct 2020 20:41:04 -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: <20201005234104.GD5177@ziepe.ca> References: <20201002233118.GM9916@ziepe.ca> <20201004125059.GP9916@ziepe.ca> <20201005172854.GA5177@ziepe.ca> <20201005183704.GC5177@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 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? > 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 Jason