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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 8D700C388F9 for ; Wed, 4 Nov 2020 16:27:14 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 C163D206DB for ; Wed, 4 Nov 2020 16:27:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="i+/uTvjs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C163D206DB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id F1EFF6E128; Wed, 4 Nov 2020 16:27:12 +0000 (UTC) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) by gabe.freedesktop.org (Postfix) with ESMTPS id C09106E128 for ; Wed, 4 Nov 2020 16:27:11 +0000 (UTC) Received: by mail-ot1-x342.google.com with SMTP id 79so12375220otc.7 for ; Wed, 04 Nov 2020 08:27:11 -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=+jKBsc1XM8CUKlg3VqmwM4QNdUSjpFH4yWF5dp0NTz8=; b=i+/uTvjsk976DicxcEHtNNkKd5tdb/MRp5JTe2+pAxIGQwwKIuIcHCZ9gIfNuEktop Ir1VcTIHdqTsD4wZdHCdfVujbxPqzBZ00Mm5Mu7qHa2cbwKkBevm00cgHWq320ih38Ge yItaK3iWE/DQC0jvHc3VxVW7uMRTu+v2PtiCM= 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=+jKBsc1XM8CUKlg3VqmwM4QNdUSjpFH4yWF5dp0NTz8=; b=NExFCfOs5FSQPeHPGRd3ntEtaSXuajMNwZzJvky/yGzaSTL7AyUCkaxaFTo4FqWRNO xL7Lifa7bANgl8MJTxDL1uCLd963dI6UxZ0B+7YienBcAOLrsCkEO6l0iKxCia8W4hNg Q+ySHgz8hcExw3fruskZzlijcL7LrhtH0T6uhTqfkmdPNRNoWLTiQb5BeRoCsHmTRC1g 4TnRG7VsUC1UTs244VNawBBbNV/8G2Mww1kh7jAqJwwksgoguZ0+JfpNTh6UkvqvywnH 9i9Z4JvbKBBuXi5HaWth1XwI2Y1VhLREpYxvmmeLOibYvBfzgzDK7ZD9t8X7S4E1IMf2 m5jw== X-Gm-Message-State: AOAM531oeVqxQMi2+xmRwICtv7uSwNT7iKcllwxeG5+At2qOUMpZpb+t tVqJsyDsjFg6ljB6i9DkKA5mcUQ8SKfed9Oeu7gPNQ== X-Google-Smtp-Source: ABdhPJwUkm33VhszJycM92X0W59/Lqj2SzkWRtSj8SP7VfVhLWlLHPhV+pa9uC6mpn9OH9RSQm2eEqL7TT7PFN/zowU= X-Received: by 2002:a9d:3b4:: with SMTP id f49mr18948455otf.188.1604507229909; Wed, 04 Nov 2020 08:27:09 -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> <20201104162125.GA13007@infradead.org> In-Reply-To: <20201104162125.GA13007@infradead.org> From: Daniel Vetter Date: Wed, 4 Nov 2020 17:26:58 +0100 Message-ID: Subject: Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM To: Christoph Hellwig X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-samsung-soc , Jan Kara , Pawel Osciak , KVM list , Linux MM , John Hubbard , LKML , DRI Development , Tomasz Figa , Jason Gunthorpe , J??r??me Glisse , "open list:DMA BUFFER SHARING FRAMEWORK" , Daniel Vetter , Kyungmin Park , Andrew Morton , Mauro Carvalho Chehab , Dan Williams , Linux ARM , Marek Szyprowski Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Nov 4, 2020 at 5:21 PM Christoph Hellwig wrote: > > On Wed, Nov 04, 2020 at 04:54:19PM +0100, Daniel Vetter wrote: > > 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. > > dma_mmap_* memory may or may not be page backed, but it absolutely > must not be resolved by get_user_pages and friends as it is special. > So yes, not being able to get a struct page back from such an mmap is > a feature. Yes, that's clear. What we're discussing is whether gup_fast and pup_fast also obey this, or fall over and can give you the struct page that's backing the dma_mmap_* memory. Since the _fast variant doesn't check for vma->vm_flags, and afaict that's the only thing which closes this gap. And like you restate, that would be a bit a problem. So where's that check which Jason&me aren't spotting? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel