Messages in this thread | | | Date | Mon, 28 Feb 2022 19:20:56 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCHv4 01/30] x86/mm: Fix warning on build with X86_MEM_ENCRYPT=y |
| |
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.
-- Kirill A. Shutemov
| |