>Number:         3252
>Category:       kern
>Synopsis:       coredump should not dump mmap'ed devices
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 24 13:50:01 1997
>Last-Modified:
>Originator:     Matthias Drochner
>Organization:
	KFA Juelich
>Release:        NetBSD-current, seems longstanding
>Environment:
	NetBSD-current, i386
System: NetBSD zel024 1.2C NetBSD 1.2C (TULIP) #24: Mon Feb 24 19:50:02 MET 1997 drochner@zelz27:/home/drochner/netbsd-970206/sys/arch/i386/compile/TULIP i386


>Description:
	A coredump can have bad side effects if there is a device (character
special file mmap'ed by the program. In my case the machine locked up, but it
is generally unwanted to perform hardware actions while dumping core. Because
the device driver mmap interface doesn't have means to tell if there is sensible
hardware behind the memory window these areas should not be dumped.
(assuming that it hurts less that mmap'ed /dev/mem or /dev/zero can not be
seen in the coredump) 

>How-To-Repeat:
	difficult
>Fix:
	There must be a better solution, but

*** vm_unix.c.orig      Mon Feb 24 22:02:47 1997
--- vm_unix.c   Mon Feb 24 22:00:06 1997
***************
*** 188,191 ****
--- 188,200 ----
                }

+               if (entry->object.vm_object &&
+                   entry->object.vm_object->pager &&
+                   entry->object.vm_object->pager->pg_type == PG_DEVICE) {
+ #ifdef DEBUG
+                   printf("vm_coredump: skipping dev @ %x\n", (int)entry->start);
+ #endif
+                   continue;
+               }
+
                if (!(entry->protection & VM_PROT_WRITE))
                        continue;

helped.
>Audit-Trail:
>Unformatted: