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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB3B4C19F28 for ; Wed, 3 Aug 2022 10:18:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237392AbiHCKSK (ORCPT ); Wed, 3 Aug 2022 06:18:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56630 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233057AbiHCKSD (ORCPT ); Wed, 3 Aug 2022 06:18:03 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB8E0B3C; Wed, 3 Aug 2022 03:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1659521882; x=1691057882; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=wFam+LDcRbKILr0ubXYReeOGRVLmWUy4n8feDpXT4KY=; b=jixmJUcG97PKX5ZUa28+bVmJitLlvDDyE5XCz7Ngn6Sxs2fCCk346OQh /e7FPrzxv/OdN4siefyhkCmDrmkJFuKi1quptgBEu6/s5XmygcajKBJyS ZrsivssBk6Q7Shs30NldTHjA62ZsniOd/HXGIDXlrTKGtCc5gAS4ZwvNo qo42XvQaBejZVxpSQUtCDI1QrL1sCc3Xo8xti8W/but3T4lGXOid1a2+Z es7fB9RoKojXChzirRk7Rdgt+2K7OkYwaS65MVYx5fSlXPS65iNPv2qhQ +W/GCziMYhi4xBvRcr6NoRpWxw/cDdJjsMT1swi02fnY9YKHgpQp6glME Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10427"; a="351350449" X-IronPort-AV: E=Sophos;i="5.93,213,1654585200"; d="scan'208";a="351350449" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2022 03:18:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,213,1654585200"; d="scan'208";a="631095811" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.193.75]) by orsmga008.jf.intel.com with ESMTP; 03 Aug 2022 03:17:51 -0700 Date: Wed, 3 Aug 2022 18:13:04 +0800 From: Chao Peng To: Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, linux-kselftest@vger.kernel.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song Subject: Re: [PATCH v7 08/14] KVM: Rename mmu_notifier_* Message-ID: <20220803101304.GE607465@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <20220706082016.2603916-9-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 29, 2022 at 07:02:12PM +0000, Sean Christopherson wrote: > On Wed, Jul 06, 2022, Chao Peng wrote: > > The sync mechanism between mmu_notifier and page fault handler employs > > fields mmu_notifier_seq/count and mmu_notifier_range_start/end. For the > > to be added private memory, there is the same mechanism needed but not > > rely on mmu_notifier (It uses new introduced memfile_notifier). This > > patch renames the existing fields and related helper functions to a > > neutral name mmu_updating_* so private memory can reuse. > > mmu_updating_* is too broad of a term, e.g. page faults and many other operations > also update the mmu. Although the name most definitely came from the mmu_notifier, > it's not completely inaccurate for other sources, e.g. KVM's MMU is still being > notified of something, even if the source is not the actual mmu_notifier. > > If we really want a different name, I'd vote for nomenclature that captures the > invalidation aspect, which is really what the variables are all trackng, e.g. > > mmu_invalidate_seq > mmu_invalidate_in_progress > mmu_invalidate_range_start > mmu_invalidate_range_end Looks good to me. Thanks. Chao