* [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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ messages in thread
end of thread, other threads:[~2026-06-04 13:57 UTC | newest]
Thread overview: 9+ 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox