Re: Which architectures need to sync vmalloc mappings between processes?

[James Bottomley <James.Bottomley@SteelEye.com>]

On Sat, 2007-02-17 at 21:29 -0800, Jeremy Fitzhardinge wrote:
> I'm looking at making all architectures export a vmalloc_sync_all()
> function, so that generic code can be sure that a particular vmalloc
> mapping is present in all address spaces.   I need this to implement a
> function to reserve a chunk of vmalloc address space complete with
> constructed pagetables, but without allocating any actual data pages.
> 
> On i386 with PAE, this is not necessary because the kernel's mappings
> are shared between all processes anyway, so it would be a no-op.  
> However, non-PAE i386 has a separate kernel mapping for each process,
> and so needs to sync them - typically lazily on faults, but
> vmalloc_sync_all exists to allow mass syncing when required.
> 
> What other architectures would require syncing of vmalloc mappings, and
> what architectures would implement it as a no-op?

Er, but there are fundamental assumptions that vmalloc_sync_all() makes
that simply aren't true on other architectures.  Really, it's an
artifact of the Intel x86 processor's inability to flush by %cr3, so we
try to keep the kernel mappings alive in a process so that a sys call
and return doesn't do a full TLB flush ... and thus, because we have a
hidden piece of kernel in userspace, we get the HIGHMEM issues.

A substantial number of other architectures do have a selective TLB
flush, so a lot operate with a fully separated kernel and user space,
and thus vmalloc mappings appear only in the single kernel address space
and nowhere else.

Could you elaborate on exactly what you think you need
vmalloc_sync_all() exported for ... your explanation of a reserved
vmalloc range sounds reasonable, but should in no way depend on
vmalloc_sync_all().  It really sounds like this should be an arch
specific function so the architectures can decide the implementation
details.

James