On Tue, 12 Feb 2013 15:35:34 -0600 Cliff Wickman <cpw@xxxxxxx> wrote: > > Commenting on this patch ended with Andrea's post on 07Jan, which was > a more-or-less endorsement and a question about support for extended vma > abstractions in kernel modules out of tree. > (that comment can be found at http://marc.info/?l=linux-mm&m=135757292605395&w=2) > > I'd like to make the request again to consider export of these two symbols. > > > We at SGI have a need to address some very high physical address ranges with > our GRU (global reference unit), sometimes across partitioned machine boundaries > and sometimes with larger addresses than the cpu supports. > We do this with the aid of our own 'extended vma' module which mimics the vma. > When something (either unmap or exit) frees an 'extended vma' we use the mmu > notifiers to clean them up. > > We had been able to mimic the functions __mmu_notifier_invalidate_range_start() > and __mmu_notifier_invalidate_range_end() by locking the per-mm lock and > walking the per-mm notifier list. But with the change to a global srcu > lock (static in mmu_notifier.c) we can no longer do that. Our module has > no access to that lock. > > So we request that these two functions be exported. > > ... > > +EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start); > +EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_end); erk. Having remote, modular, out-of-tree *sending* mmu notifications is pretty abusive :( I don't have a problem with the patch personally. It's a GPL export and it's only 2 lines and if we break it, you own both pieces ;) But in a better world, the core kernel would support your machines adequately and you wouldn't need to maintain that out-of-tree MM code. What are the prospects of this? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>