From owner-freebsd-hackers Sun Jan 26 13:30:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25427 for hackers-outgoing; Sun, 26 Jan 1997 13:30:47 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA25422; Sun, 26 Jan 1997 13:30:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id NAA08138; Sun, 26 Jan 1997 13:30:26 -0800 (PST) Message-Id: <199701262130.NAA08138@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Luigi Rizzo cc: dyson@freebsd.org, hackers@freebsd.org Subject: Re: exec bug In-reply-to: Your message of "Sun, 26 Jan 1997 14:17:12 +0100." <199701261317.OAA28121@labinfo.iet.unipi.it> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 13:30:26 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >> 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. > >I was referring to the soft case. the blocking read only leaves >the process hung, and possibly not dying at shutdown. But an nfs >'soft' read timing out with a failure, isn't it a time-bomb ? Like I said, I'm not sure what will happen. The system might just leave a zeroed page in memory which would cause execve() to return a exec format failure to the process. On the other hand, it probably will return a fault failure and cause a panic...I just don't know for sure. In any case, using 'soft' mounts for executables is a bad idea no matter how you slice it...it shouldn't kill the system, however. >> > 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 > >you mean "was not fatal" dont you ? No, I mean that you only take special action in the failure case, so that is the case you want to know about. >> have for this is signals, and that doesn't work when you're executing in the >> kernel like this. > >I don't know the "big picture" so this could be totally nonsense, >but how about creating a "page_probe()" function, cooperating with >the fault handler, which tries to access the page, returning 1 if >any page fault occur in the kernel address space while running ? >Then exec_aout_imgact() (or any other critical function) could >first page_probe() the required page, then either continue or fail. >There shouldn't be much penalty in doing this since at most the >page gets paged in, something that would be necessary anyways. See my last reply to Bruce. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project