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 D8EF9C4727E for ; Wed, 7 Oct 2020 13:14:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 29CDF20870 for ; Wed, 7 Oct 2020 13:14:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="E2hqgrVA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29CDF20870 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3CBBF8E0003; Wed, 7 Oct 2020 09:14:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 37C788E0001; Wed, 7 Oct 2020 09:14:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 291FA8E0003; Wed, 7 Oct 2020 09:14:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0221.hostedemail.com [216.40.44.221]) by kanga.kvack.org (Postfix) with ESMTP id ED35C8E0001 for ; Wed, 7 Oct 2020 09:14:31 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 850A61EE6 for ; Wed, 7 Oct 2020 13:14:31 +0000 (UTC) X-FDA: 77345173542.27.birth64_4a08927271cf Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 614BF3D663 for ; Wed, 7 Oct 2020 13:14:31 +0000 (UTC) X-HE-Tag: birth64_4a08927271cf X-Filterd-Recvd-Size: 5481 Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Wed, 7 Oct 2020 13:14:30 +0000 (UTC) Received: by mail-qt1-f196.google.com with SMTP id j22so1705428qtj.8 for ; Wed, 07 Oct 2020 06:14:30 -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=l1/PDrUGxFWlwqR1FTUvguUx8J1SxRzs8uzlhmmTvw3nxztGKSpSwyT18BTm2/l5fl 8f46K5UoCXFWAhbhIrDTU3nDllRe/9jseD1IxGDf05MZa1vTFNIlUe4TiqKVLu/tZAd0 jWIR6Jb4xEeOqkUTqgj1rtC+JGxzdR1bZkiKpz2YY6GFYDe7WNR3XBr6vnnMyV91QYVJ 8/H7m7FnotBS/BxMor5yrXFhi2gO98KOZP+Y8WoxO6M3UuLm5/aMYBMGlY+S+dxvKvOC VTahHqvv6Iesx08Oj07FrgZOAMs8IDlajJuWN0UzPf0KLrgqmc1u7rFQ13nrSq3wJ9QZ y+yw== X-Gm-Message-State: AOAM532jQQB70TqBcq0g8dkRnSB0PUaXCilWi21S4u2Mzz5uDOfgC3UC M3TvDKkwJ8ll3L70uN/SKuT8Lg== 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 Cc: Daniel Vetter , 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 , 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: <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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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