PR/51148 CVS commit: src/sys/arch

["Maxime Villard" <maxv%netbsd.org@localhost>]

The following reply was made to PR kern/51148; it has been noted by GNATS.

From: "Maxime Villard" <maxv%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/51148 CVS commit: src/sys/arch
Date: Thu, 26 May 2016 07:24:55 +0000

 Module Name:	src
 Committed By:	maxv
 Date:		Thu May 26 07:24:55 UTC 2016
 
 Modified Files:
 	src/sys/arch/amd64/amd64: locore.S
 	src/sys/arch/i386/i386: locore.S
 
 Log Message:
 There is an issue in the way the fillkpt macro sets up pages on both
 amd64 and i386.
 
 The fillkpt loop is equivalent to the following:
 
 	do {
 		/* fill in the slot */
 		/* increment %ebx to the next slot */
 		/* increment %eax to the next pa */
 	} while (%ecx > 0)
 
 The issue here is that if %ecx = 0 (i.e., the chunk we are trying to
 map is zero-sized), there is still one entry created in the page table.
 The kernel expects the va<->pa translation to be linear in low memory.
 If there is a zero-sized chunk, the dead entry creates a +4096 offset in
 the virtual space, with two consecutive entries that point to the same
 physical address. In other words, the mappings are not linear anymore,
 which causes the kernel to die.
 
 Before my recent changes, there were only two big chunks that were
 mapped, and neither of these could be zero-sized. Now, with multiple,
 fine-grained chunks, it is possible that the [SYMS]+[PRELOADED_MODULES]
 chunk could be zero-sized.
 
 [PRELOADED_MODULES] is almost never here, and [SYMS] is always here on
 default kernels. Except for floppies, where the bootloader does not load
 [SYMS].
 
 Should fix PR 51148.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.93 -r1.94 src/sys/arch/amd64/amd64/locore.S
 cvs rdiff -u -r1.124 -r1.125 src/sys/arch/i386/i386/locore.S
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.