VMALLOC_END, TASK_SIZE and FIXADDR_START for 64 bit MIPS kernels

VMALLOC_END, TASK_SIZE and FIXADDR_START for 64 bit MIPS kernels

[Guenter Roeck]

Hi,

since it came up during the review of the patch for virtual memory detection
on 64 bit mips kernels, I looked further into making vmalloc_end
a variable and TASK_SIZE dependent on the virtual memory size.
 
That turned out to be relatively straightforward, and I have a working patch.

The one question I still have is about FIXADDR_START.  It is currently
set to one of 0xff000000, 0xfffe0000, or (0xff000000 - 0x20000),
depending on the target CPU.

Quoting from one of the comments during the review,
	" ... ensure the value of vmalloc_end is <= FIXADDR_START".

Obviously that is currently not the case. Is that a concern, or is it good as it is ?

Thanks,
Guenter

Re: VMALLOC_END, TASK_SIZE and FIXADDR_START for 64 bit MIPS kernels

[Ralf Baechle]

On Wed, Feb 03, 2010 at 02:22:50PM -0800, Guenter Roeck wrote:

> since it came up during the review of the patch for virtual memory detection
> on 64 bit mips kernels, I looked further into making vmalloc_end
> a variable and TASK_SIZE dependent on the virtual memory size.
>  
> That turned out to be relatively straightforward, and I have a working patch.
> 
> The one question I still have is about FIXADDR_START.  It is currently
> set to one of 0xff000000, 0xfffe0000, or (0xff000000 - 0x20000),
> depending on the target CPU.
> 
> Quoting from one of the comments during the review,
> 	" ... ensure the value of vmalloc_end is <= FIXADDR_START".
> 
> Obviously that is currently not the case. Is that a concern, or is it good as it is ?

Now with allocations potencially happening top-down this is potencially a
serious problem.  Details would depend on details of platform, processor and
kernel configuration.

I said vmalloc_end is <= FIXADDR_START" but more accurately we simply
need to avoid a conflict between the different virtual address space users.

Some CPUs have fixed mappings in their hardware in the KSEG2/KSEG3 range;
those mappings can't be overriden by a TLB mapping.  To deal with that
sort of architectural candy I think a call into the address space allocator
for kernel virtual memory is probably nicest thing but something simplier
than that would probable have to do for 2.6.34.

  Ralf