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 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 2A280C433E3 for ; Fri, 21 Aug 2020 13:02:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EB1E4207BB for ; Fri, 21 Aug 2020 13:02:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB1E4207BB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=chris-wilson.co.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7B2096B002B; Fri, 21 Aug 2020 09:02:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7635D6B002C; Fri, 21 Aug 2020 09:02:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67A2B6B002D; Fri, 21 Aug 2020 09:02:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0043.hostedemail.com [216.40.44.43]) by kanga.kvack.org (Postfix) with ESMTP id 510A06B002B for ; Fri, 21 Aug 2020 09:02:23 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0AD4C181AEF1D for ; Fri, 21 Aug 2020 13:02:23 +0000 (UTC) X-FDA: 77174589366.01.brake27_1005cd127039 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id F00391004F62C for ; Fri, 21 Aug 2020 13:02:15 +0000 (UTC) X-HE-Tag: brake27_1005cd127039 X-Filterd-Recvd-Size: 3062 Received: from fireflyinternet.com (unknown [77.68.26.236]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Aug 2020 13:02:06 +0000 (UTC) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 22198351-1500050 for multiple; Fri, 21 Aug 2020 14:01:43 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20200821085011.28878-1-chris@chris-wilson.co.uk> <20200821085011.28878-2-chris@chris-wilson.co.uk> Subject: Re: [PATCH 2/4] drm/i915/gem: Sync the vmap PTEs upon construction From: Chris Wilson Cc: Linux Kernel Mailing List , intel-gfx , Linux-MM , Pavel Machek , Andrew Morton , Joerg Roedel , Dave Airlie , Joonas Lahtinen , Rodrigo Vivi , stable To: Linus Torvalds Date: Fri, 21 Aug 2020 14:01:41 +0100 Message-ID: <159801490171.29194.13892566081151243171@build.alporthouse.com> User-Agent: alot/0.9 X-Rspamd-Queue-Id: F00391004F62C X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Quoting Linus Torvalds (2020-08-21 13:41:03) > On Fri, Aug 21, 2020 at 1:50 AM Chris Wilson w= rote: > > > > Since synchronising the PTE after assignment is a manual step, use the > > newly exported interface to flush the PTE after assigning via > > alloc_vm_area(). >=20 > This commit message doesn't make much sense to me. >=20 > Are you talking about synchronizing the page directory structure > across processes after possibly creating new kernel page tables? >=20 > Because that has nothing to do with the PTE. It's all about making > sure the _upper_ layers of the page directories are populated > everywhere.. >=20 > The name seems off to me too - what are you "flushing"? (And yes, I > know about the flush_cache_vmap(), but that looks just bogus, since > any non-mapped area shouldn't have any virtual caches to begin with, > so I suspect that is just the crazy architectures being confused - > flush_cache_vmap() is a no-op on any sane architecture - and powerpc > that mis-uses it for other things). I was trying to mimic map_kernel_range() which does the arch_sync_kernel_mappings and flush_cache_vmap on top of the apply_to_page_range performed by alloc_vm_area, because buried away in there, on x86-32, is a set_pmd(). Since map_kernel_range() wrapped map_kernel_range_noflush(), flush seemed like the right verb. Joerg pointed out that the sync belonged to __apply_to_page_range and fixed it in situ. -Chris