Date: Wed, 16 Dec 1998 22:23:53 -0700 (MST) From: David G Andersen <danderse@cs.utah.edu> To: karl@Denninger.Net (Karl Denninger) Cc: bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: yup, found it (NFS) Message-ID: <199812170523.WAA02697@lal.cs.utah.edu> In-Reply-To: <19981216230855.A27443@Denninger.Net> from "Karl Denninger" at Dec 16, 98 11:08:56 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Lo and behold, Karl Denninger once said:
>
> On Wed, Dec 16, 1998 at 11:51:39PM -0500, Alfred Perlstein wrote:
> > On Wed, 16 Dec 1998, Karl Denninger wrote:
> >
> > > Remove the intr for now. If that fixes it then at least we have
> > > hard proof of where it is.
It does. You may wish to look at PR kern/8732, which we opened about a
month ago on exactly this topic.
> > > cause. This of course assumes you mount executable directories (very
> > > common in clusters) across NFS.
Interesting. We didn't bump into this one, but my test program didn't
check for it - only for the buffer flushing.
> > > Certainly the expected execution path is basically the same, and I can
> > > *trigger it* with a SIGINT to a running process which happens to have some
> > > of its working set paged out at the time it receives the signal (ouch!)
> >
> > That doesn't seem very good at all. Is this second case for all
> > NFS mounts? or only intr mounts?
If it's like the bug we found (which I'd wager), it's probably for intr
mounts. Like we mention in the PR, the problem seems to be related to the
change from sleep to an interruptable tsleep.
> What I want to know is whether a "ro,soft" mount has the same
> vulnerability. We use them around here for things like mounting
> the Usenet spool.
Nope. Soft doesn't seem to affect it (at least, the last time I tested
it). Another cheap fix is to not run any nfsiods, preventing the
asynchronous flush from occuring in the first place.
We've been hounding on this PR for a while (that's kern/8732. :), and
would love to see a resolution for it. If someone wants to suggest the
proper behavior, I'm more than happy to start drudging up a fix.
-Dave
--
work: danderse@cs.utah.edu me: angio@pobox.com
University of Utah http://www.angio.net/
Department of Computer Science
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812170523.WAA02697>