On Thu, 4 Jun 2026 at 12:51, Sumit Semwal <[email protected]> wrote: > > Hi All, > > On Thu, 4 Jun 2026 at 11:04, Maxime Ripard <[email protected]> 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
