On 2/16/24 08:56, Catalin Marinas wrote: ...
The problem is that the contpte_* symbols are called from the ptep_* inline functions. So where those inlines are called from modules, we need to make sure the contpte_* symbols are available. John Hubbard originally reported this problem against v1 and I enumerated all the drivers that call into the ptep_* inlines here: https://lore.kernel.org/linux-arm-kernel/b994ff89-1a1f-26ca-9479-b08c77f94be8@xxxxxxx/#t So they definitely need to be exported. Perhaps we can tighten it to
Yes. Let's keep the in-tree modules working.
EXPORT_SYMBOL_GPL(), but I was being cautious as I didn't want to break anything out-of-tree. I'm not sure what the normal policy is? arm64 seems to use ~equal amounts of both.
EXPORT_SYMBOL_GPL() seems appropriate and low risk. As Catalin says below, these really are deeply core mm routines, and any module operating at this level is not going to be able to survive on EXPORT_SYMBOL alone, IMHO. Now, if only I could find an out of tree module to test that claim on... :)
I don't think we are consistent here. For example set_pte_at() can't be called from non-GPL modules because of __sync_icache_dcache. OTOH, such driver is probably doing something dodgy. Same with apply_to_page_range(), it's GPL-only (called from i915). Let's see if others have any view over the next week or so, otherwise I'd go for _GPL and relax it later if someone has a good use-case (can be a patch on top adding _GPL).
I think going directly to _GPL for these is fine, actually. thanks, -- John Hubbard NVIDIA
