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/