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.8 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 19344C4742C for ; Wed, 4 Nov 2020 15:54:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 44A6B22280 for ; Wed, 4 Nov 2020 15:54:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="PitcG0uA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 44A6B22280 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6AAEE6B0036; Wed, 4 Nov 2020 10:54:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 65A8F6B0068; Wed, 4 Nov 2020 10:54:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 548B06B0070; Wed, 4 Nov 2020 10:54:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) by kanga.kvack.org (Postfix) with ESMTP id 2621A6B0036 for ; Wed, 4 Nov 2020 10:54:33 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B37F8180AD806 for ; Wed, 4 Nov 2020 15:54:32 +0000 (UTC) X-FDA: 77447183184.15.hook19_2900dd7272c2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 9215C1814B0C8 for ; Wed, 4 Nov 2020 15:54:32 +0000 (UTC) X-HE-Tag: hook19_2900dd7272c2 X-Filterd-Recvd-Size: 5109 Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Wed, 4 Nov 2020 15:54:31 +0000 (UTC) Received: by mail-ot1-f66.google.com with SMTP id h62so19695031oth.9 for ; Wed, 04 Nov 2020 07:54:31 -0800 (PST) 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=y5iSM0n3L7+OTVROVCVTwu3uWAzU5mN6qUkDTEIh4do=; b=PitcG0uAHrmeOMZWf07+5nFovh7kr7Adgn3pV0IjFTvWK31RX96qNAX9Ks5Dh/x/M1 BTJhllHwgJtYkqu+DoGQVr+zvfuKEAes8E2EKiqu7lnWd/wgVh9ipY9g1P/exu8Ll0XH MlM5Nev4kEpw3fiAkWDQeeOa/AbBbn0nfEjrM= 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=y5iSM0n3L7+OTVROVCVTwu3uWAzU5mN6qUkDTEIh4do=; b=ZE3dlyCLzga47L8EgpRLemDYkLpvF/oJJx39hu16uYnwZtSqqpbUfTcqpUQbrAxsw8 e28bT2zDY7iPw59sqbMbGnYKIJVwL2zvmB9wyYNidXYHsiVeF5iGKN2JZyKOP8StzNET jpcqRmqmY0bhiG8ZkY17aFo307znZ5+7Nn+ghtq8AwPqWcRHARgtTIDyrDWwiA7MdH5Y xm2t1+YYvDERzaCYLO6mQxh7egvCc50Mb1vLwxiK93L0Z7GTjCJmH/UxtE9w5bjOedxh jMKye+49l6h/SbE8aWzx0D8VcyiicmEiHG7wBHeGNwsRQ0cU2Qx6yhNk1RqOjFAgakBu hg/g== X-Gm-Message-State: AOAM530k9tEqWHySFbKjkSH3GnzE45xPmrvyC4kvNgs29DEIMd2/vQbY MUC3IOiueSgngu5s3KoPAbeOjrIlFlfq7s5BrFRTZg== X-Google-Smtp-Source: ABdhPJwFTZ6h8d4LZSz0ZdASZtc67ts9b22F6yGqx4swNCRA+uz1tGrz0fV1z6m2B8vN3lXuyoPJEYkFgolkB9M18jE= X-Received: by 2002:a9d:3b4:: with SMTP id f49mr18846565otf.188.1604505270511; Wed, 04 Nov 2020 07:54:30 -0800 (PST) MIME-Version: 1.0 References: <20201030100815.2269-1-daniel.vetter@ffwll.ch> <20201030100815.2269-6-daniel.vetter@ffwll.ch> <446b2d5b-a1a1-a408-f884-f17a04b72c18@nvidia.com> <1f7cf690-35e2-c56f-6d3f-94400633edd2@nvidia.com> <7f29a42a-c408-525d-90b7-ef3c12b5826c@nvidia.com> <20201104140023.GQ36674@ziepe.ca> In-Reply-To: <20201104140023.GQ36674@ziepe.ca> From: Daniel Vetter Date: Wed, 4 Nov 2020 16:54:19 +0100 Message-ID: Subject: Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM To: Jason Gunthorpe Cc: John Hubbard , DRI Development , LKML , KVM list , Linux MM , Linux ARM , linux-samsung-soc , "open list:DMA BUFFER SHARING FRAMEWORK" , Daniel Vetter , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Tomasz Figa , Mauro Carvalho Chehab , Andrew Morton , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Dan Williams Content-Type: text/plain; charset="UTF-8" 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, Nov 4, 2020 at 3:00 PM Jason Gunthorpe wrote: > > On Sun, Nov 01, 2020 at 11:50:39PM +0100, Daniel Vetter wrote: > > > It's not device drivers, but everyone else. At least my understanding > > is that VM_IO | VM_PFNMAP means "even if it happens to be backed by a > > struct page, do not treat it like normal memory". And gup/pup_fast > > happily break that. I tried to chase the history of that test, didn't > > turn up anything I understood much: > > VM_IO isn't suppose do thave struct pages, so how can gup_fast return > them? > > I thought some magic in the PTE flags excluded this? I don't really have a box here, but dma_mmap_attrs() and friends to mmap dma_alloc_coherent memory is set up as VM_IO | VM_PFNMAP (it's actually enforced since underneath it uses remap_pfn_range), and usually (except if it's pre-cma carveout) that's just normal struct page backed memory. Sometimes from a cma region (so will be caught by the cma page check), but if you have an iommu to make it device-contiguous, that's not needed. I think only some architectures have a special io pte flag, and those are only used for real mmio access. And I think the popular ones all don't. But that stuff is really not my expertise, just some drive-by reading I've done to understand how the pci mmap stuff works (which is special in yet other ways I think). So probably I'm missing something, but I'm not seeing anything that prevents this from coming out of a pup/gup_fast. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch