Subject: kern/6455: mmap()/munmap() in mdsetimage fails to modify mmap'ed file
To: None <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: netbsd-bugs
Date: 11/18/1998 00:48:47
>Number:         6455
>Category:       kern
>Synopsis:       mmap()/munmap() in mdsetimage fails to modify mmap'ed file
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 18 00:50:02 1998
>Originator:     Jonathan Stone
>Release:        NetBSD 1.3H as at 1998-11-14
System: NetBSD Cuisinart.Stanford.EDU 1.3H NetBSD 1.3H (EGCS-HAIFA) #15: Sun Nov 15 17:05:22 PST 1998 jonathan@Cuisinart.Stanford.EDU:/cuisinart/compile/EGCS-HAIFA pmax


mdsetimage, when run on an mips writing kernel, reports success but
does not acutally alter the data space of the `modified' kernel.
it appears to be a bug in mmap()/munmap().


Build usr/src/usr.sbin/mdsetimage on a pmax with UVM kernel, compiled
with EGCS plus Haifa.

Build a kernel with spae for a ramdisk, e.g., via::

	# Pull in standard `install' config
	include "arch/pmax/conf/INSTALL"
	# Pull in optional local configuration
	include "arch/pmax/conf/RAMDISK.local"
	# Enable the hooks used for initializing the root memory-disk.
	options         MEMORY_DISK_HOOKS
	options         MEMORY_DISK_IS_ROOT     # force root on memory disk
	options         MEMORY_DISK_SERVER=0    # no userspace memory disk support
	options         MINIROOTSIZE=4096       # size of memory disk, in blocks (2MB)
	# File systems: need MFS
	file-system     MFS     	        # memory file system
	# Extra Pseudo-Devices
	# disk/mass storage pseudo-devices
	pseudo-device   md              1       # memory disk device (ramdisk)

Put together a 2mb file of non-zero data of your choice.  (i use the
distrib/pmax tools to build a 2meg ramdisk on vnd.)

Copy the kernel to Do `mdsetimage' on the kernel and the
2mb file.  Compare the saved kernel to the one supposedy mdsetimage'd.
On my machine, the two kernels are identical; there is no change to
the initalized-data segment where the md should reside.

Neil A. Carson <> reports the same symptoms
on arm32.


I tried the following patch, based on independent discussion of
another UVM bug with Chuck Cranor.  It masks the problem for me, but
as best i understand mmap() of MAP_SHARED|MAP_FILE regions, this
should not be necesary.  (it isnt on other ports like i386 or alpha).
I suspect the underlying cause remains, and could still cause
undetected data loss in other situations.

Index: mdsetimage.c
RCS file: /cvsroot/src/usr.sbin/mdsetimage/mdsetimage.c,v
retrieving revision 1.7
diff -u -r1.7 mdsetimage.c
--- mdsetimage.c	1998/08/27 18:03:44	1.7
+++ mdsetimage.c	1998/11/17 23:10:57
@@ -163,6 +163,12 @@
+	if (verbose)
+		fprintf(stderr, "unmapping %s\n", kfile);
+	rv = msync(mappedkfile, ksb.st_size, MS_SYNC);
+	if (rv != 0)
+		errx(1, "could not write modifications to file %s", kfile);
 	munmap(mappedkfile, ksb.st_size);