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, 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 4FA70C4741F for ; Mon, 9 Nov 2020 08:52:49 +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 E9EAB206ED for ; Mon, 9 Nov 2020 08:52:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E9EAB206ED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com 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 0B4358966B; Mon, 9 Nov 2020 08:52:32 +0000 (UTC) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id 330DC89266 for ; Mon, 9 Nov 2020 08:44:47 +0000 (UTC) IronPort-SDR: 0IP8Hq1WSFjmYMG6KK2t+3jISCfodoY9oaF/pAXVhfxoKrXBCIA1XNdcHBqUr3ODkx0U77nN7q JuvNbwwWiIMQ== X-IronPort-AV: E=McAfee;i="6000,8403,9799"; a="233935717" X-IronPort-AV: E=Sophos;i="5.77,463,1596524400"; d="scan'208";a="233935717" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Nov 2020 00:44:46 -0800 IronPort-SDR: IfG8q/sA5EMlyMjSvfUVNc+EaAlzDVZgRGJpX0K7ztOK0lomesX1KEuchnWCGhkYW9POxwry58 wHJVsBh0G9fA== X-IronPort-AV: E=Sophos;i="5.77,463,1596524400"; d="scan'208";a="540750920" Received: from sfhansen-mobl.ger.corp.intel.com ([10.249.254.141]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Nov 2020 00:44:40 -0800 Message-ID: <504d77b87c81b7027157e0c7b5286e17123c59d9.camel@linux.intel.com> Subject: Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Jason Gunthorpe , Daniel Vetter Date: Mon, 09 Nov 2020 09:44:02 +0100 In-Reply-To: <20201106125505.GO36674@ziepe.ca> References: <20201104163758.GA17425@infradead.org> <20201104164119.GA18218@infradead.org> <20201104181708.GU36674@ziepe.ca> <20201105092524.GQ401619@phenom.ffwll.local> <20201105124950.GZ36674@ziepe.ca> <7ae3486d-095e-cf4e-6b0f-339d99709996@nvidia.com> <20201106125505.GO36674@ziepe.ca> User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Nov 2020 08:52:30 +0000 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 , KVM list , Pawel Osciak , John Hubbard , LKML , DRI Development , Tomasz Figa , Christoph Hellwig , Linux MM , 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 Fri, 2020-11-06 at 08:55 -0400, Jason Gunthorpe wrote: > On Fri, Nov 06, 2020 at 11:27:59AM +0100, Daniel Vetter wrote: > > On Fri, Nov 6, 2020 at 11:01 AM Daniel Vetter > > wrote: > > > On Fri, Nov 6, 2020 at 5:08 AM John Hubbard > > > wrote: > > > > On 11/5/20 4:49 AM, Jason Gunthorpe wrote: > > > > > On Thu, Nov 05, 2020 at 10:25:24AM +0100, Daniel Vetter > > > > > wrote: > > > > > > > /* > > > > > > > * If we can't determine whether or not a pte is > > > > > > > special, then fail immediately > > > > > > > * for ptes. Note, we can still pin HugeTLB and THP as > > > > > > > these are guaranteed not > > > > > > > * to be special. > > > > > > > * > > > > > > > * For a futex to be placed on a THP tail page, > > > > > > > get_futex_key requires a > > > > > > > * get_user_pages_fast_only implementation that can pin > > > > > > > pages. Thus it's still > > > > > > > * useful to have gup_huge_pmd even if we can't operate > > > > > > > on ptes. > > > > > > > */ > > > > > > > > > > > > We support hugepage faults in gpu drivers since recently, > > > > > > and I'm not > > > > > > seeing a pud_mkhugespecial anywhere. So not sure this > > > > > > works, but probably > > > > > > just me missing something again. > > > > > > > > > > It means ioremap can't create an IO page PUD, it has to be > > > > > broken up. > > > > > > > > > > Does ioremap even create anything larger than PTEs? > > > > > > gpu drivers also tend to use vmf_insert_pfn* directly, so we can > > > do > > > on-demand paging and move buffers around. From what I glanced for > > > lowest level we to the pte_mkspecial correctly (I think I > > > convinced > > > myself that vm_insert_pfn does that), but for pud/pmd levels it > > > seems > > > just yolo. > > > > So I dug around a bit more and ttm sets PFN_DEV | PFN_MAP to get > > past > > the various pft_t_devmap checks (see e.g. > > vmf_insert_pfn_pmd_prot()). > > x86-64 has ARCH_HAS_PTE_DEVMAP, and gup.c seems to handle these > > specially, but frankly I got totally lost in what this does. > > The fact vmf_insert_pfn_pmd_prot() has all those BUG_ON's to prevent > putting VM_PFNMAP pages into the page tables seems like a big red > flag. > > The comment seems to confirm what we are talking about here: > > /* > * If we had pmd_special, we could avoid all these > restrictions, > * but we need to be consistent with PTEs and architectures > that > * can't support a 'special' bit. > */ > > ie without the ability to mark special we can't block fast gup and > anyone who does O_DIRECT on these ranges will crash the kernel when > it > tries to convert a IO page into a struct page. > > Should be easy enough to directly test? > > Putting non-struct page PTEs into a VMA without setting VM_PFNMAP > just > seems horribly wrong to me. Although core mm special huge-page support is currently quite limited, some time ago, I extended the pre-existing vma_is_dax() to vma_is_special_huge(): /** * vma_is_special_huge - Are transhuge page-table entries considered special? * @vma: Pointer to the struct vm_area_struct to consider * * Whether transhuge page-table entries are considered "special" following * the definition in vm_normal_page(). * * Return: true if transhuge page-table entries should be considered special, * false otherwise. */ static inline bool vma_is_special_huge(const struct vm_area_struct *vma) { return vma_is_dax(vma) || (vma->vm_file && (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))); } meaning that currently all transhuge page-table-entries in a PFNMAP or MIXEDMAP vma are considered "special". The number of calls to this function (mainly in the page-splitting code) is quite limited so replacing it with a more elaborate per-page-table-entry scheme would, I guess, definitely be possible. Although all functions using it would need to require a fallback path for architectures not supporting it. /Thomas > > Jason _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel