[PATCH] x86: Remove various memory encryption exports

[PATCH] x86: Remove various memory encryption exports

[Christoph Hellwig]

None of these is used in modular code, and we should probably try to
keep it that way.  They can be added back if we really get a legitimate
modular user.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---

FYI: this was inspired by the fact the s390 copied some of the exports,
which made me wonder why they added them.  I could not find any
potential users either in their patchkit nor in mainline.

 arch/x86/mm/mem_encrypt.c | 2 --
 arch/x86/mm/pageattr.c    | 2 --
 2 files changed, 4 deletions(-)

diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 385afa2b9e17..031e7702bd1e 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -339,13 +339,11 @@ bool sme_active(void)
 {
 	return sme_me_mask && !sev_enabled;
 }
-EXPORT_SYMBOL(sme_active);
 
 bool sev_active(void)
 {
 	return sme_me_mask && sev_enabled;
 }
-EXPORT_SYMBOL(sev_active);
 
 /* Architecture __weak replacement functions */
 void __init mem_encrypt_free_decrypted_mem(void)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 4c570612e24e..9d83c724293a 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -2066,13 +2066,11 @@ int set_memory_encrypted(unsigned long addr, int numpages)
 {
 	return __set_memory_enc_dec(addr, numpages, true);
 }
-EXPORT_SYMBOL_GPL(set_memory_encrypted);
 
 int set_memory_decrypted(unsigned long addr, int numpages)
 {
 	return __set_memory_enc_dec(addr, numpages, false);
 }
-EXPORT_SYMBOL_GPL(set_memory_decrypted);
 
 int set_pages_uc(struct page *page, int numpages)
 {
-- 
2.20.1

Re: [PATCH] x86: Remove various memory encryption exports

[Borislav Petkov]

On Sat, Apr 27, 2019 at 08:19:35AM +0200, Christoph Hellwig wrote:
> None of these is used in modular code, and we should probably try to
> keep it that way.  They can be added back if we really get a legitimate
> modular user.

You're going to love this:

87df26175e67 ("x86/mm: Unbreak modules that rely on external PAGE_KERNEL availability")

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.