[PATCHv10 06/18] x86/mm: Make x86_platform.guest.enc_status_change_*() return errno

[Kirill A. Shutemov]

On Sun, Apr 28, 2024 at 07:25:57PM +0200, Borislav Petkov wrote:
> On Tue, Apr 09, 2024 at 02:29:58PM +0300, Kirill A. Shutemov wrote:
> > TDX is going to have more than one reason to fail
> > enc_status_change_prepare().
> > 
> > Change the callback to return errno instead of assuming -EIO;
> > enc_status_change_finish() changed too to keep the interface symmetric.
> 
> "Change enc_status_change_finish() too... "
> 
> "Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
> instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
> to do frotz", as if you are giving orders to the codebase to change
> its behaviour."

Hm. I considered the sentence to be in imperative mood already. I guess I
don't fully understand what imperative mood is. Will fix.

> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov at linux.intel.com>
> > Reviewed-by: Dave Hansen <dave.hansen at intel.com>
> > Reviewed-by: Kai Huang <kai.huang at intel.com>
> > Tested-by: Tao Liu <ltao at redhat.com>
> > ---
> >  arch/x86/coco/tdx/tdx.c         | 20 +++++++++++---------
> >  arch/x86/hyperv/ivm.c           | 22 ++++++++++------------
> >  arch/x86/include/asm/x86_init.h |  4 ++--
> >  arch/x86/kernel/x86_init.c      |  4 ++--
> >  arch/x86/mm/mem_encrypt_amd.c   |  8 ++++----
> >  arch/x86/mm/pat/set_memory.c    |  8 +++++---
> >  6 files changed, 34 insertions(+), 32 deletions(-)
> 
> Another thing you should long know by now: get_maintainer.pl. You do
> know that when you send a patch which touches multiple different
> "places", you run it through get_maintainer.pl to get some hints as to
> who to CC, right?

You are right, I didn't run get_maintainer.pl this time. I never got it
integrated properly into my workflow. How do you use it? Is it part of
'git send-email' hooks or do you do it manually somehow.

I don't feel I can trust the script to do The Right Thing™ all the time
to put into my hooks. I expect it to blow up on tree-wide patches for
instance.

As result I only run it occasionally, when I remember to which is
suboptimal.

Any tips?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov