From owner-freebsd-bugs  Mon Jan 20 18:46:46 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id SAA21718
          for bugs-outgoing; Mon, 20 Jan 1997 18:46:46 -0800 (PST)
Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA21711
          for <bugs@freebsd.org>; Mon, 20 Jan 1997 18:46:41 -0800 (PST)
Received: from newport.ece.uci.edu by meter.eng.uci.edu (8.8.4) id SAA19555; Mon, 20 Jan 1997 18:46:36 -0800 (PST)
Received: from localhost by newport.ece.uci.edu (8.8.4) id SAA23170; Mon, 20 Jan 1997 18:46:33 -0800 (PST)
Message-Id: <199701210246.SAA23170@newport.ece.uci.edu>
To: bugs@freebsd.org
Subject: exec panic in 2.2 RELENG
Date: Mon, 20 Jan 1997 18:46:32 -0800
From: Steven Wallace <swallace@ece.uci.edu>
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


I have discovered a problem with 2.2 execing a binary image when
the first page has bad blocks on the media.

For example, I have a CDROM where a file has all its blocks are bad,
so when it execs, the header is mapped, then exec_aout_imgact()
is called and accesses this page, then the system panics because
it faults while in kernel mode.

The problem as I see it is that in execve() we have:

	/*
	 * Map the image header (first page) of the file into
	 *	kernel address space
	 */
	error = vm_mmap(exech_map,			/* map */
			...

I don't know if this call reads that page in from the filesystem.
Apparently it does not.  It should read this page into memory.
If there are any problems, then an error is returned immediately.
We will be accessing this page the next function call anyways,
so we might as well bring it in now.  Also, this allows us to
detect any errors right away.

Please let me know the results of your investigation.  I can test
it out on my bad media for you.

Steven