Messages in this thread | | | From | kumon@flab ... | Date | Wed, 29 Sep 1999 17:58:08 +0900 | Subject | Memory management bug in 2.3.16 or after |
| |
Small correction to my previous mail.
kumon@flab.fujitsu.co.jp writes: > 2. The former code assumes "start_mem <= MEM < end_mem", but the > latter code assumes "start_mem < MEM <= end_mem. > This will cause unused first page around start_mem and > nonexistent memory access around end_mem.
Actually, "end_mem" is not the physical limit, so extending end_mem doesn't cause nonexistent memory access, but the vmalloc area just follows after the area pointed by end_mem. So extending MEM over end_mem may cause some anomalies to vmalloc() operation.
But by viewing from the vmalloc() side, there is unnatural coding which may prevent this interference.
linux-2.3/linux-2.3.18/include/asm-i386/pgtable.h:
151:#define VMALLOC_OFFSET (8*1024*1024) 152:#define VMALLOC_START (((unsigned long) high_memory + VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1))
In mem_init(), "end_mem" value is copied into "high_memory", we can think the "high_memory" is equal to the "end_mem".
# High_memory is a global variable and end_mem is the local argument # to the mem_init().
Usually, round-up to the nearest boundary is achieved like: (X + (TWOS_POWER - 1)) & (TWOS_POWER-1)
but the above pgtable.h code seems: (X + (TWOS_POWER )) & (TWOS_POWER-1)
If X is the multiple of TWOS_POWER, this round-up results one block after that of desired.
In the typical machine configuration, memory is installed multiple of 8 Mbyte size and the variable 'end_mem" will be also multiple of 8M.
In this situation, VMALLOC_START is always at "high_memory+8M" and thus, the very first portion of vmalloc-area is fortunately protected from the interference.
May it be intended?
-- Computer Systems Laboratory, Fujitsu Labs. kumon@flab.fujitsu.co.jp
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |