Date: Sun, 26 Jan 1997 13:30:26 -0800 From: David Greenman <dg@root.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: dyson@freebsd.org, hackers@freebsd.org Subject: Re: exec bug Message-ID: <199701262130.NAA08138@root.com> In-Reply-To: Your message of "Sun, 26 Jan 1997 14:17:12 %2B0100." <199701261317.OAA28121@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701262130.NAA08138>