From owner-freebsd-current Sun Jan 26 04:42:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA05639 for current-outgoing; Sun, 26 Jan 1997 04:42:19 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA05630 for ; Sun, 26 Jan 1997 04:42:17 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA27988; Sun, 26 Jan 1997 13:00:04 +0100 From: Luigi Rizzo Message-Id: <199701261200.NAA27988@labinfo.iet.unipi.it> Subject: Re: exec bug To: dg@root.com Date: Sun, 26 Jan 1997 13:00:03 +0100 (MET) Cc: swallace@ece.uci.edu, current@FreeBSD.ORG In-Reply-To: <199701261239.EAA06801@root.com> from "David Greenman" at Jan 26, 97 04:38:52 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> >execve() maps the first page to memory and calls exec_aout_imgact() > >> >which then accesses this page and fails. The system then gets > >> >a page fault while in kernel mode and dies. > > > >Given this description, would this also occur when trying to run > >a program from an nfs-mounted partition which at some point becomes > >unavailable ? If not (as I hope!) what is the difference ? > > In the case of NFS, the read should block indefinately. I'm not sure what > will happen if the NFS is mounted "soft", however. that would be a major problem then! Wouldn't it be possible to track the exact reason of the fault inside the handler and avoid panicing ? After all there are no performance problems at that point.. Thanks Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________