Date: Sun, 26 Jan 1997 05:36:03 -0800 From: David Greenman <dg@root.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: swallace@ece.uci.edu, current@FreeBSD.ORG Subject: Re: exec bug Message-ID: <199701261336.FAA06928@root.com> In-Reply-To: Your message of "Sun, 26 Jan 1997 13:00:03 %2B0100." <199701261200.NAA27988@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >> >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! Not any more so than any other read blocking indefinately. > 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.. ...and just how do you tell the exec code that a page fault that occured while it was accessing the image header was "fatal"? The only mechanism we have for this is signals, and that doesn't work when you're executing in the kernel like this. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701261336.FAA06928>