lkml.org 
[lkml]   [1999]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectMemory 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.028 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site