Re: [PATCHv4 01/30] x86/mm: Fix warning on build with X86_MEM_ENCRYPT=y

[Josh Poimboeuf <jpoimboe@redhat.com>]

On Mon, Feb 28, 2022 at 07:20:56PM +0300, Kirill A. Shutemov wrote:
> On Sun, Feb 27, 2022 at 02:01:30PM -0800, Josh Poimboeuf wrote:
> > On Thu, Feb 24, 2022 at 06:56:01PM +0300, Kirill A. Shutemov wrote:
> > > So far, AMD_MEM_ENCRYPT is the only user of X86_MEM_ENCRYPT. TDX will be
> > > the second. It will make mem_encrypt.c build without AMD_MEM_ENCRYPT,
> > > which triggers a warning:
> > > 
> > > arch/x86/mm/mem_encrypt.c:69:13: warning: no previous prototype for
> > > 	function 'mem_encrypt_init' [-Wmissing-prototypes]
> > > 
> > > Fix it by moving mem_encrypt_init() declaration outside of #ifdef
> > > CONFIG_AMD_MEM_ENCRYPT.
> > > 
> > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > > Fixes: 20f07a044a76 ("x86/sev: Move common memory encryption code to mem_encrypt.c")
> > > Acked-by: David Rientjes <rientjes@google.com>
> > 
> > The patch title, warning, and "Fixes" tag tend to give the impression
> > this is fixing a real user-visible bug.  But the bug is theoretical, as
> > it's not possible to enable X86_MEM_ENCRYPT without AMD_MEM_ENCRYPT,
> > until patch 27.
> > 
> > IMO it would be preferable to just squash this change with patch 27.
> > 
> > Having it as a separate patch is also fine, but it shouldn't be
> > described as a fix or use the Fixes tag.  It's more of a preparatory
> > patch.
> 
> maintainer-tip.rst seems disagree with you:
> 
>    A Fixes tag should be added even for changes which do not need to be
>    backported to stable kernels, i.e. when addressing a recently introduced
>    issue which only affects tip or the current head of mainline.
> 
> I will leave it as is.

How does that disagree with me?

The "Fixes" tag is for bug fixes.  If it's not possible to trigger the
warning and there's no user impact, it's not a bug.

-- 
Josh