On Mon, Jun 8, 2026 at 8:27 AM Jason Gunthorpe <[email protected]> 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 <[email protected]> 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.
