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 703CCC6FA82 for ; Sun, 4 Sep 2022 15:49:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234627AbiIDPtb (ORCPT ); Sun, 4 Sep 2022 11:49:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234332AbiIDPtZ (ORCPT ); Sun, 4 Sep 2022 11:49:25 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72028DEC; Sun, 4 Sep 2022 08:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662306564; x=1693842564; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=9r82ZTSuD0x+QvHSVy2lzg+W+9scndMmZbzkLh1CQPM=; b=XBqPxJh+GcpszFbdqbqSXJDCUVQTM7le8T4DltMg2ax6/+j/kpLFp8YH rO6GivNHOL4eHNdl1FpcKgUinRwUTE3zsTVOdwTu03iLuj/8/b/oEaPUJ N9XTCUTBzqimLDnCDQ6RgWcgrKPNOPyNZYFdpHVmAWKg4nu2m2zowL0O1 TeTPtRi7nnkwTGyfWw6IUAcc3TCgkVuaaS+j8tjiTrS2xvrK8huKbRQEv okIN/gGlj5agaGot8O6ahCRJLRYG6vCM8l/TWTvuJMC4UTkcR0kwsSMCV UOjfoswomal8bX+sHzFKFxq2IhsQfopVODAAxYV3b0H8zaVFk5pXXwCYf w==; X-IronPort-AV: E=McAfee;i="6500,9779,10460"; a="297553926" X-IronPort-AV: E=Sophos;i="5.93,289,1654585200"; d="scan'208";a="297553926" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Sep 2022 08:49:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,289,1654585200"; d="scan'208";a="674974980" Received: from liuzhao-optiplex-7080.sh.intel.com (HELO localhost) ([10.239.160.132]) by fmsmga008.fm.intel.com with ESMTP; 04 Sep 2022 08:49:20 -0700 Date: Sun, 4 Sep 2022 23:54:15 +0800 From: Zhao Liu To: Dave Hansen Cc: Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, "Fabio M. De Francesco" , Ira Weiny , Zhenyu Wang , Zhao Liu Subject: Re: [PATCH] KVM: SVM: Replace kmap_atomic() with kmap_local_page() Message-ID: References: <20220902090811.2430228-1-zhao1.liu@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, Sep 02, 2022 at 08:09:29AM -0700, Dave Hansen wrote: > This changelog is a little on the weak side. You could literally take > any arbitrary call-site and file for kmap_atomic() and slap that > changelog on it. For instance: > > In drivers/target/target_core_sbc.c, the function > sbc_dif_copy_prot() doesn't need to disable pagefaults and > preemption in kmap_atomic(). It can simply use kmap_local_page() > / kunmap_local() that can instead do the mapping / unmapping > regardless of the context. > > With kmap_local_page(), the mapping is per thread, CPU local and > not globally visible. Therefore, sbc_dif_copy_prot() is a > function where the use of kmap_local_page() in place of > kmap_atomic() is correctly suited. > > That's all valid English and there's nothing incorrect in it. But, it > doesn't indicate that any actual analysis was performed. It's utterly > generic. It could literally have been generated by a pretty trivial script. > > It would be great to add at least a small, call-site-specific human > touch to these changelogs. > > In this case, saying something about how global the cache flush is would > be a great addition. Thanks Dave! I'll add more detail to the commit message and avoid overly templated changelogs. Zhao