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 CFD83C4363D for ; Wed, 7 Oct 2020 13:16:08 +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 57EFC206F4 for ; Wed, 7 Oct 2020 13:16:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FdkIT/OT"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="E2hqgrVA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57EFC206F4 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=WfSeXWkaxydN1cJE8VlmKaufGl78MqqFQRb6iezAJjg=; b=FdkIT/OTpE0V0FEmwhM/if/X4 h1WhzyZIbmLbGyj5v39TZXruXTFVvPVdPygxSdhGKQav6SFVTvEI0RjO6hhPnfZi7NAlu00KhBVc4 liJe7XmVpAGqa4Aav0OkW2eHRfISt4H4RgmPPGpyAyZwiLZ8c94gD1J+a8FEegfqvKlhrBWymI1mx kHW8Bxj2UAC6SUJmT6L900Yltgu5Gfqkrx8Qn0K8RqGYPzD2Vtj6Yx0sj+oK0wFzmdkfFgGJ3nKQt jdA6bSUJJujbeNWY9vtrI6D/CfHwk2ZYq4A5L29TS34qNLrbe8DY1LbXJuMouj7g9JzJm/6u42s/3 gXAccKNaw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQ9H9-0000vJ-E9; Wed, 07 Oct 2020 13:14:35 +0000 Received: from mail-qt1-x841.google.com ([2607:f8b0:4864:20::841]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQ9H6-0000tx-LA for linux-arm-kernel@lists.infradead.org; Wed, 07 Oct 2020 13:14:33 +0000 Received: by mail-qt1-x841.google.com with SMTP id h12so166667qtu.1 for ; Wed, 07 Oct 2020 06:14:31 -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=MmLkeDGPsMUHS0xvj3eEHFFmVdpcqhu0PPjOEhkFDRw=; b=E2hqgrVAYT0hzmQlUY2vSFECyG02KQklk4Q7aygEUVLS/VVeb3Tt27E/79H/UOl+9G SJBQ/lGMxMqipGbxoj7lfw0USKf2Sj6n3xYaQY9FvYamgoh5eKN5yzmXYMdRJ0LcIIqz VwpDBuIBc7R3DFnysJ6dY3hWBTL2Armw0wdMzfr++A3aRDehnCNFpI553/T5UM+DRyuQ Oek61rl8sZvLcPOv1smXPcbXY2ExA/erB9R5Jr+rymqCoLjWHjzuaE4tUHHAgHy+quP5 QhDpDcvG1j+JZTxnHpIfusLhcypJ7HAV8RlkRBnFjKu3NO5ifvRL25XEKGsOMPhDPufR tnZQ== 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=MmLkeDGPsMUHS0xvj3eEHFFmVdpcqhu0PPjOEhkFDRw=; b=X2KB1K6207lBeIWea5rtUp0CMaq17fRTOFEAyEiehiBe8/0Be6EOhEdsh6ZQwCL20N OA/9sF94/9HTEQgSJTuFeXSjBKoNep3HJFOLJvvfM1tZPnwqyWZ4AY7E4WW/ZVYx5m/+ PIkscCfWbQ1hJXyFyi88RPIY+HMSUMlDoVbzlq9EvJwEc0vkz9jKD6Hnm4l1gGwdqTpZ cm9/cCIEe7cX7oDYvG9v872WO5/F9xI4Icup6KLq++1tKlVwMSSqGETsxRPsE7um2boW I+62J5xaueUDZaIogOaBlE0wrmr4gRvll9Q1aQ0CMyNkFWyF7rLGdTu8/C/2j/bXu9Hx YG6w== X-Gm-Message-State: AOAM530Ddn+KqyKD5+nzHyyFIvDXi36rxCil0kPFhfN8nF+3BrcK6lrY UdgJuVf3BzolfgB6hFfBU+lp5Q== X-Google-Smtp-Source: ABdhPJz8yWeQeFkSjjqVWhH1mXFkaZDdDkKqUssPTxNJCo0OrdjKtKBs9eNFjrd0s56SqUYqYVTBxw== X-Received: by 2002:ac8:71c6:: with SMTP id i6mr3077500qtp.318.1602076469886; Wed, 07 Oct 2020 06:14:29 -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 m15sm352795qtc.90.2020.10.07.06.14.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2020 06:14:29 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kQ9H2-000u0D-Lc; Wed, 07 Oct 2020 10:14:28 -0300 Date: Wed, 7 Oct 2020 10:14:28 -0300 From: Jason Gunthorpe To: Tomasz Figa Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Message-ID: <20201007131428.GQ5177@ziepe.ca> References: <20201002175303.390363-1-daniel.vetter@ffwll.ch> <20201002175303.390363-2-daniel.vetter@ffwll.ch> <20201002180603.GL9916@ziepe.ca> <20201002233118.GM9916@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-20201007_091432_715608_F6E46CB7 X-CRM114-Status: GOOD ( 15.51 ) 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 , Daniel Vetter , Seung-Woo Kim , LKML , DRI Development , Kyungmin Park , Linux MM , =?utf-8?B?SsOpcsO0bWU=?= Glisse , John Hubbard , 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 Wed, Oct 07, 2020 at 03:06:17PM +0200, Tomasz Figa wrote: > Note that vb2_vmalloc is only used for in-kernel CPU usage, e.g. the > contents being copied by the driver between vb2 buffers and some > hardware FIFO or other dedicated buffers. The memory does not go to > any hardware DMA. That is even worse, the CPU can't just blindly touch VM_IO pages, that isn't portable. > Could you elaborate on what "the REQUIRED behavior is"? I can see that > both follow the get_vaddr_frames() -> frame_vector_to_pages() flow, as > you mentioned. Perhaps the only change needed is switching to > pin_user_pages after all? It is the comment right on top of get_vaddr_frames(): if @start belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures and the caller must make sure pfns aren't reused for anything else while he is using them. Which means excluding every kind of VMA that is not something this driver understands and then using special knowledge of the driver-specific VMA to assure the above. For instance if you could detect the VMA is from a carevout and do something special like hold the fget() while knowning that the struct file guarentees the carveout remains reserved - then you could use follow_pfn. But it would be faster and better to ask the carveout FD for the vaddr range. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel