* [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted
@ 2026-05-22 22:58 T.J. Mercier
2026-05-25 6:21 ` Christoph Hellwig
0 siblings, 1 reply; 12+ messages in thread
From: T.J. Mercier @ 2026-05-22 22:58 UTC (permalink / raw)
To: maddy, mpe, npiggin, chleroy, linuxppc-dev, mripard, sumit.semwal
Cc: lkp, linux-kernel, T.J. Mercier
After commit fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a
module") the system dma-buf heaps can be built as a module. The
system_cc_shared heap uses set_memory_encrypted and set_memory_decrypted
but those functions are not exported on powerpc. This can result in a
build error like:
>> ERROR: modpost: "set_memory_decrypted" [drivers/dma-buf/heaps/system_heap.ko] undefined!
>> ERROR: modpost: "set_memory_encrypted" [drivers/dma-buf/heaps/system_heap.ko] undefined!
Export the functions so system_heap.ko can be built.
Reported-by: kernel test robot <lkp@intel•com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605230046.E9uhmQXM-lkp@intel.com/
Fixes: fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a module")
Signed-off-by: T.J. Mercier <tjmercier@google•com>
---
arch/powerpc/platforms/pseries/svm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/svm.c b/arch/powerpc/platforms/pseries/svm.c
index 384c9dc1899a..59cf32e51ca3 100644
--- a/arch/powerpc/platforms/pseries/svm.c
+++ b/arch/powerpc/platforms/pseries/svm.c
@@ -50,6 +50,7 @@ int set_memory_encrypted(unsigned long addr, int numpages)
return 0;
}
+EXPORT_SYMBOL_GPL(set_memory_encrypted);
int set_memory_decrypted(unsigned long addr, int numpages)
{
@@ -63,6 +64,8 @@ int set_memory_decrypted(unsigned long addr, int numpages)
return 0;
}
+EXPORT_SYMBOL_GPL(set_memory_decrypted);
+
/* There's one dispatch log per CPU. */
#define NR_DTL_PAGE (DISPATCH_LOG_BYTES * CONFIG_NR_CPUS / PAGE_SIZE)
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted 2026-05-22 22:58 [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted T.J. Mercier @ 2026-05-25 6:21 ` Christoph Hellwig 2026-05-27 16:07 ` Jason Gunthorpe 0 siblings, 1 reply; 12+ messages in thread From: Christoph Hellwig @ 2026-05-25 6:21 UTC (permalink / raw) To: T.J. Mercier Cc: maddy, mpe, npiggin, chleroy, linuxppc-dev, mripard, sumit.semwal, lkp, linux-kernel, iommu, linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams, Tom Lendacky, x86 On Fri, May 22, 2026 at 03:58:53PM -0700, T.J. Mercier wrote: > After commit fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a > module") the system dma-buf heaps can be built as a module. The > system_cc_shared heap uses set_memory_encrypted and set_memory_decrypted > but those functions are not exported on powerpc. This can result in a > build error like: I'd much rather revert the above commit. Yes, x86 has exported these since 2017, but that's a really bad idea, and we should fix it instead of spreading the export. Setting memory decrypted is a dangerous operations and should only be available to core code. We should have various allocators for decrypted code, but not export the functionality to random code. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted 2026-05-25 6:21 ` Christoph Hellwig @ 2026-05-27 16:07 ` Jason Gunthorpe 2026-05-27 18:15 ` Borislav Petkov 2026-06-04 5:34 ` Maxime Ripard 0 siblings, 2 replies; 12+ messages in thread From: Jason Gunthorpe @ 2026-05-27 16:07 UTC (permalink / raw) To: Christoph Hellwig Cc: T.J. Mercier, maddy, mpe, npiggin, chleroy, linuxppc-dev, mripard, sumit.semwal, lkp, linux-kernel, iommu, linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams, Tom Lendacky, x86 On Sun, May 24, 2026 at 11:21:33PM -0700, Christoph Hellwig wrote: > On Fri, May 22, 2026 at 03:58:53PM -0700, T.J. Mercier wrote: > > After commit fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a > > module") the system dma-buf heaps can be built as a module. The > > system_cc_shared heap uses set_memory_encrypted and set_memory_decrypted > > but those functions are not exported on powerpc. This can result in a > > build error like: > > I'd much rather revert the above commit. Yes, x86 has exported these > since 2017, but that's a really bad idea, and we should fix it instead > of spreading the export. > > Setting memory decrypted is a dangerous operations and should only > be available to core code. We should have various allocators for > decrypted code, but not export the functionality to random code. At the very least an EXPORT_SYMBOL_NS. Looks like there are about 3 modules using it already.. Jason ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted 2026-05-27 16:07 ` Jason Gunthorpe @ 2026-05-27 18:15 ` Borislav Petkov 2026-05-28 8:53 ` Christoph Hellwig 2026-06-04 5:34 ` Maxime Ripard 1 sibling, 1 reply; 12+ messages in thread From: Borislav Petkov @ 2026-05-27 18:15 UTC (permalink / raw) To: Jason Gunthorpe Cc: Christoph Hellwig, T.J. Mercier, maddy, mpe, npiggin, chleroy, linuxppc-dev, mripard, sumit.semwal, lkp, linux-kernel, iommu, linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams, Tom Lendacky, x86 On Wed, May 27, 2026 at 01:07:16PM -0300, Jason Gunthorpe wrote: > > Setting memory decrypted is a dangerous operations and should only > > be available to core code. We should have various allocators for > > decrypted code, but not export the functionality to random code. > > At the very least an EXPORT_SYMBOL_NS. > > Looks like there are about 3 modules using it already.. Looks like more to me... In any case, we exported them back then for some framebuffer things: 95cf9264d5f3 ("x86, drm, fbdev: Do not specify encrypted memory for video mappings") -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted 2026-05-27 18:15 ` Borislav Petkov @ 2026-05-28 8:53 ` Christoph Hellwig 0 siblings, 0 replies; 12+ messages in thread From: Christoph Hellwig @ 2026-05-28 8:53 UTC (permalink / raw) To: Borislav Petkov Cc: Jason Gunthorpe, Christoph Hellwig, T.J. Mercier, maddy, mpe, npiggin, chleroy, linuxppc-dev, mripard, sumit.semwal, lkp, linux-kernel, iommu, linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams, Tom Lendacky, x86 On Wed, May 27, 2026 at 11:15:49AM -0700, Borislav Petkov wrote: > On Wed, May 27, 2026 at 01:07:16PM -0300, Jason Gunthorpe wrote: > > > Setting memory decrypted is a dangerous operations and should only > > > be available to core code. We should have various allocators for > > > decrypted code, but not export the functionality to random code. > > > > At the very least an EXPORT_SYMBOL_NS. > > > > Looks like there are about 3 modules using it already.. > > Looks like more to me... > > In any case, we exported them back then for some framebuffer things: > > 95cf9264d5f3 ("x86, drm, fbdev: Do not specify encrypted memory for video mappings") Which is exactly one of these things that should not happen - mapping random I/O memory without the proper helpers.. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted 2026-05-27 16:07 ` Jason Gunthorpe 2026-05-27 18:15 ` Borislav Petkov @ 2026-06-04 5:34 ` Maxime Ripard 2026-06-04 7:21 ` Sumit Semwal 1 sibling, 1 reply; 12+ messages in thread From: Maxime Ripard @ 2026-06-04 5:34 UTC (permalink / raw) To: Jason Gunthorpe Cc: Christoph Hellwig, T.J. Mercier, maddy, mpe, npiggin, chleroy, linuxppc-dev, sumit.semwal, lkp, linux-kernel, iommu, linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams, Tom Lendacky, x86 [-- Attachment #1: Type: text/plain, Size: 1218 bytes --] On Wed, May 27, 2026 at 01:07:16PM -0300, Jason Gunthorpe wrote: > On Sun, May 24, 2026 at 11:21:33PM -0700, Christoph Hellwig wrote: > > On Fri, May 22, 2026 at 03:58:53PM -0700, T.J. Mercier wrote: > > > After commit fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a > > > module") the system dma-buf heaps can be built as a module. The > > > system_cc_shared heap uses set_memory_encrypted and set_memory_decrypted > > > but those functions are not exported on powerpc. This can result in a > > > build error like: > > > > I'd much rather revert the above commit. Yes, x86 has exported these > > since 2017, but that's a really bad idea, and we should fix it instead > > of spreading the export. > > > > Setting memory decrypted is a dangerous operations and should only > > be available to core code. We should have various allocators for > > decrypted code, but not export the functionality to random code. > > At the very least an EXPORT_SYMBOL_NS. > > Looks like there are about 3 modules using it already.. So, I'm not really sure how to fix this now. Should we revert the patch making the system heap a module, or should we export the symbols for all archs? Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 273 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted 2026-06-04 5:34 ` Maxime Ripard @ 2026-06-04 7:21 ` Sumit Semwal 2026-06-04 7:32 ` Sumit Semwal 2026-06-04 13:57 ` Jason Gunthorpe 0 siblings, 2 replies; 12+ messages in thread From: Sumit Semwal @ 2026-06-04 7:21 UTC (permalink / raw) To: Maxime Ripard, Jiri Pirko Cc: Jason Gunthorpe, Christoph Hellwig, T.J. Mercier, maddy, mpe, npiggin, chleroy, linuxppc-dev, lkp, linux-kernel, iommu, linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams, Tom Lendacky, x86 Hi All, On Thu, 4 Jun 2026 at 11:04, Maxime Ripard <mripard@kernel•org> wrote: > > On Wed, May 27, 2026 at 01:07:16PM -0300, Jason Gunthorpe wrote: > > On Sun, May 24, 2026 at 11:21:33PM -0700, Christoph Hellwig wrote: > > > On Fri, May 22, 2026 at 03:58:53PM -0700, T.J. Mercier wrote: > > > > After commit fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a > > > > module") the system dma-buf heaps can be built as a module. The > > > > system_cc_shared heap uses set_memory_encrypted and set_memory_decrypted > > > > but those functions are not exported on powerpc. This can result in a > > > > build error like: > > > > > > I'd much rather revert the above commit. Yes, x86 has exported these > > > since 2017, but that's a really bad idea, and we should fix it instead > > > of spreading the export. > > > > > > Setting memory decrypted is a dangerous operations and should only > > > be available to core code. We should have various allocators for > > > decrypted code, but not export the functionality to random code. > > > > At the very least an EXPORT_SYMBOL_NS. > > > > Looks like there are about 3 modules using it already.. > > So, I'm not really sure how to fix this now. Should we revert the patch > making the system heap a module, or should we export the symbols for all > archs? Given that Christoph's objection is not really about the modules part, but that the set_memory_{encrypted,decrypted} should not be used here, one option is to revert 78b30c50a7ac until that issue is sorted out? Jiri, any thoughts from you? > > Maxime Best, Sumit. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted 2026-06-04 7:21 ` Sumit Semwal @ 2026-06-04 7:32 ` Sumit Semwal 2026-06-04 13:57 ` Jason Gunthorpe 1 sibling, 0 replies; 12+ messages in thread From: Sumit Semwal @ 2026-06-04 7:32 UTC (permalink / raw) To: Maxime Ripard, Jiri Pirko Cc: Jason Gunthorpe, Christoph Hellwig, T.J. Mercier, maddy, mpe, npiggin, chleroy, linuxppc-dev, lkp, linux-kernel, iommu, linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams, Tom Lendacky, x86 On Thu, 4 Jun 2026 at 12:51, Sumit Semwal <sumit.semwal@linaro•org> wrote: > > Hi All, > > On Thu, 4 Jun 2026 at 11:04, Maxime Ripard <mripard@kernel•org> wrote: > > > > On Wed, May 27, 2026 at 01:07:16PM -0300, Jason Gunthorpe wrote: > > > On Sun, May 24, 2026 at 11:21:33PM -0700, Christoph Hellwig wrote: > > > > On Fri, May 22, 2026 at 03:58:53PM -0700, T.J. Mercier wrote: > > > > > After commit fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a > > > > > module") the system dma-buf heaps can be built as a module. The > > > > > system_cc_shared heap uses set_memory_encrypted and set_memory_decrypted > > > > > but those functions are not exported on powerpc. This can result in a > > > > > build error like: > > > > > > > > I'd much rather revert the above commit. Yes, x86 has exported these > > > > since 2017, but that's a really bad idea, and we should fix it instead > > > > of spreading the export. > > > > > > > > Setting memory decrypted is a dangerous operations and should only > > > > be available to core code. We should have various allocators for > > > > decrypted code, but not export the functionality to random code. > > > > > > At the very least an EXPORT_SYMBOL_NS. > > > > > > Looks like there are about 3 modules using it already.. > > > > So, I'm not really sure how to fix this now. Should we revert the patch > > making the system heap a module, or should we export the symbols for all > > archs? > > Given that Christoph's objection is not really about the modules part, > but that the set_memory_{encrypted,decrypted} should not be used here, > one option is to revert 78b30c50a7ac until that issue is sorted out? > > Jiri, any thoughts from you? Argh, I'm sorry I missed that some modules are already using it. I apologise! Christoph, is there a way we could accept the symbols export for other archs if the arch maintainers are ok? Heiko seemed ok for S390, so this needs agreement for powerpc. > > > > Maxime > > Best, > Sumit. Best, Sumit ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted 2026-06-04 7:21 ` Sumit Semwal 2026-06-04 7:32 ` Sumit Semwal @ 2026-06-04 13:57 ` Jason Gunthorpe 2026-06-08 15:17 ` Sumit Semwal 1 sibling, 1 reply; 12+ messages in thread From: Jason Gunthorpe @ 2026-06-04 13:57 UTC (permalink / raw) To: Sumit Semwal Cc: Maxime Ripard, Jiri Pirko, Christoph Hellwig, T.J. Mercier, maddy, mpe, npiggin, chleroy, linuxppc-dev, lkp, linux-kernel, iommu, linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams, Tom Lendacky, x86 On Thu, Jun 04, 2026 at 12:51:49PM +0530, Sumit Semwal wrote: > Given that Christoph's objection is not really about the modules part, > but that the set_memory_{encrypted,decrypted} should not be used here, > one option is to revert 78b30c50a7ac until that issue is sorted out? Please no, we have stuff already using this so it would be a functional regression. Revert making heaps into a module since that doesn't have a functional regression. Jason ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted 2026-06-04 13:57 ` Jason Gunthorpe @ 2026-06-08 15:17 ` Sumit Semwal 2026-06-08 15:27 ` Jason Gunthorpe 0 siblings, 1 reply; 12+ messages in thread From: Sumit Semwal @ 2026-06-08 15:17 UTC (permalink / raw) To: Jason Gunthorpe Cc: Maxime Ripard, Jiri Pirko, Christoph Hellwig, T.J. Mercier, maddy, mpe, npiggin, chleroy, linuxppc-dev, lkp, linux-kernel, iommu, linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams, Tom Lendacky, x86, Arnd Bergmann Hi Jason, On Thu, 4 Jun 2026 at 19:27, Jason Gunthorpe <jgg@ziepe•ca> wrote: > > On Thu, Jun 04, 2026 at 12:51:49PM +0530, Sumit Semwal wrote: > > > Given that Christoph's objection is not really about the modules part, > > but that the set_memory_{encrypted,decrypted} should not be used here, > > one option is to revert 78b30c50a7ac until that issue is sorted out? > > Please no, we have stuff already using this so it would be a > functional regression. Revert making heaps into a module since that > doesn't have a functional regression. Thanks for your comments. To me, it looks like while system and system_cc_shared heaps share a lot of code, their user bases have different needs. It's apparent that system_cc_heap users don't care about it being a module while system heap users would very much like so. I also discussed this with Arnd, and he suggested we could rearrange the code so that system_heap_cc_shared_priv depends on a new Kconfig symbol like config DMABUF_HEAPS_CC_SYSTEM bool "DMA-BUF System Heap for memory encryption" depends on ARCH_HAS_MEM_ENCRYPT && DMABUF_HEAPS_SYSTEM=y This allows building both into the kernel or leave encryption choice up to the consumers of the system heap. If this is agreeable to everyone, I can post Arnd's patch. > > Jason Best, Sumit. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted 2026-06-08 15:17 ` Sumit Semwal @ 2026-06-08 15:27 ` Jason Gunthorpe 2026-06-08 16:04 ` T.J. Mercier 0 siblings, 1 reply; 12+ messages in thread From: Jason Gunthorpe @ 2026-06-08 15:27 UTC (permalink / raw) To: Sumit Semwal, Jiri Pirko Cc: Maxime Ripard, Jiri Pirko, Christoph Hellwig, T.J. Mercier, maddy, mpe, npiggin, chleroy, linuxppc-dev, lkp, linux-kernel, iommu, linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams, Tom Lendacky, x86, Arnd Bergmann On Mon, Jun 08, 2026 at 08:47:15PM +0530, Sumit Semwal wrote: > Hi Jason, > > On Thu, 4 Jun 2026 at 19:27, Jason Gunthorpe <jgg@ziepe•ca> wrote: > > > > On Thu, Jun 04, 2026 at 12:51:49PM +0530, Sumit Semwal wrote: > > > > > Given that Christoph's objection is not really about the modules part, > > > but that the set_memory_{encrypted,decrypted} should not be used here, > > > one option is to revert 78b30c50a7ac until that issue is sorted out? > > > > Please no, we have stuff already using this so it would be a > > functional regression. Revert making heaps into a module since that > > doesn't have a functional regression. > > Thanks for your comments. > > To me, it looks like while system and system_cc_shared heaps share a > lot of code, their user bases have different needs. It's apparent that > system_cc_heap users don't care about it being a module while system > heap users would very much like so. > > I also discussed this with Arnd, and he suggested we could rearrange > the code so that system_heap_cc_shared_priv depends on a new Kconfig > symbol like > > config DMABUF_HEAPS_CC_SYSTEM > bool "DMA-BUF System Heap for memory encryption" > depends on ARCH_HAS_MEM_ENCRYPT && DMABUF_HEAPS_SYSTEM=y > > This allows building both into the kernel or leave encryption choice > up to the consumers of the system heap. > > If this is agreeable to everyone, I can post Arnd's patch. Yeah, that's fine for me for now Jason ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted 2026-06-08 15:27 ` Jason Gunthorpe @ 2026-06-08 16:04 ` T.J. Mercier 0 siblings, 0 replies; 12+ messages in thread From: T.J. Mercier @ 2026-06-08 16:04 UTC (permalink / raw) To: Jason Gunthorpe Cc: Sumit Semwal, Jiri Pirko, Maxime Ripard, Christoph Hellwig, maddy, mpe, npiggin, chleroy, linuxppc-dev, lkp, linux-kernel, iommu, linux-mm, agordeev, gerald.schaefer, linux-s390, Dan Williams, Tom Lendacky, x86, Arnd Bergmann On Mon, Jun 8, 2026 at 8:27 AM Jason Gunthorpe <jgg@ziepe•ca> wrote: > > On Mon, Jun 08, 2026 at 08:47:15PM +0530, Sumit Semwal wrote: > > Hi Jason, > > > > On Thu, 4 Jun 2026 at 19:27, Jason Gunthorpe <jgg@ziepe•ca> wrote: > > > > > > On Thu, Jun 04, 2026 at 12:51:49PM +0530, Sumit Semwal wrote: > > > > > > > Given that Christoph's objection is not really about the modules part, > > > > but that the set_memory_{encrypted,decrypted} should not be used here, > > > > one option is to revert 78b30c50a7ac until that issue is sorted out? > > > > > > Please no, we have stuff already using this so it would be a > > > functional regression. Revert making heaps into a module since that > > > doesn't have a functional regression. > > > > Thanks for your comments. > > > > To me, it looks like while system and system_cc_shared heaps share a > > lot of code, their user bases have different needs. It's apparent that > > system_cc_heap users don't care about it being a module while system > > heap users would very much like so. > > > > I also discussed this with Arnd, and he suggested we could rearrange > > the code so that system_heap_cc_shared_priv depends on a new Kconfig > > symbol like > > > > config DMABUF_HEAPS_CC_SYSTEM > > bool "DMA-BUF System Heap for memory encryption" > > depends on ARCH_HAS_MEM_ENCRYPT && DMABUF_HEAPS_SYSTEM=y > > > > This allows building both into the kernel or leave encryption choice > > up to the consumers of the system heap. > > > > If this is agreeable to everyone, I can post Arnd's patch. > > Yeah, that's fine for me for now > > Jason +1 SGTM Thanks, T.J. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2026-06-08 16:04 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-05-22 22:58 [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted T.J. Mercier 2026-05-25 6:21 ` Christoph Hellwig 2026-05-27 16:07 ` Jason Gunthorpe 2026-05-27 18:15 ` Borislav Petkov 2026-05-28 8:53 ` Christoph Hellwig 2026-06-04 5:34 ` Maxime Ripard 2026-06-04 7:21 ` Sumit Semwal 2026-06-04 7:32 ` Sumit Semwal 2026-06-04 13:57 ` Jason Gunthorpe 2026-06-08 15:17 ` Sumit Semwal 2026-06-08 15:27 ` Jason Gunthorpe 2026-06-08 16:04 ` T.J. Mercier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox