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 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 783C5C4363A for ; Mon, 5 Oct 2020 23:42:28 +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 220442075A for ; Mon, 5 Oct 2020 23:42:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="TjYdQciZ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="WQTRkabU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 220442075A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca 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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=potxZ+FsgIvj/ajoCN9OPnZoeiOtqL8VasPwcrkPC8U=; b=TjYdQciZI/iyp2UQxf1DcSX5u PS5k0uB0kMHKmgrkudaG8K5Z5D52L0vEo56tWAxlDLeEDEMuHV8Kzl9TlzGSorAurE8GoLAQSVHHU IhTBLgDHqAZBRAlw/YDkdnXoZg7wcZDhHPrLyUMTWr/O5X/djF6/dMtDNOqUHOjysVYxpHevZhohC 2ZyOQRz2Tlx/j98Rbs+/WdBLlz5Hf7wchk8ZuCTLoZVi0APoUEDFOV2oc+MIgYsj3uOwbtomcUH9D G1QboKnKAQz4V93jsrVPlEl43vADbJw3nb1Dc91aEnjG1sqEY+1Mj38UBwltflFS5/hUnGIB0p+eK TDcmySI7Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPa6S-0004So-Qp; Mon, 05 Oct 2020 23:41:12 +0000 Received: from mail-qv1-xf44.google.com ([2607:f8b0:4864:20::f44]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPa6O-0004Rg-0s for linux-arm-kernel@lists.infradead.org; Mon, 05 Oct 2020 23:41:11 +0000 Received: by mail-qv1-xf44.google.com with SMTP id bl9so4194632qvb.10 for ; Mon, 05 Oct 2020 16:41:07 -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=K008QCtYBJ2EwSilkC7gg/gyP2GwCeKJhaYft/db0r3lasBi1OSe4qxxtRt//wxKcN Q1BhzKtDYGJTHuhwX+4reQazGlAcPyWrP0zFrIXrBUQxUhr319vQlo/OcueHXYjAZJGb Z4pXhRKxdvLgUrETaWQlLFLmKU3Xv+FzOC6erHzFr/Qo212w/Kn/+ZaIPBXj3+u86d96 yLmiystBvLw5rRPaUSElXYSwxYLXbvXagrjYFQ3ZofSeDXzLpa7y78ZhD6hGEVX0fAVq upUNITfetcPoN4PM6xZP8xmsv6RXY0aEcps5EnPQLFBTEfKPdsHMx9iEgdnqp9FIQe5w n5xQ== X-Gm-Message-State: AOAM531nzhNGNrq5p071QCbztNnKlfOahHTIwQ2H6kA0UIPYMYYY9UCI Jy60dD/o1/cOW+yjYWHdDR2wHA== 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 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201005_194108_345825_1783A491 X-CRM114-Status: GOOD ( 14.06 ) 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?SsOpcsO0bWU=?= Glisse , 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel