VMALLOC_END, TASK_SIZE and FIXADDR_START for 64 bit MIPS kernels
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
Quoted 6 lines · Guenter Roeck
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_enda variable andTASK_SIZEdependent on the virtual memory size.That turned out to be relatively straightforward, and I have a working patch.
Quoted 8 lines
The one question I still have is about
FIXADDR_START. It is currently set to one of0xff000000,0xfffe0000, or (0xff000000-0x20000), depending on the target CPU.Quoting from one of the comments during the review,
" ... ensure the value ofvmalloc_endis <=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