Date: Mon, 29 Nov 1999 23:56:31 +0100 From: Eivind Eklund <eivind@FreeBSD.ORG> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "Viren R.Shah" <viren@rstcorp.com>, freebsd-current@FreeBSD.ORG Subject: Re: repeatable crash in -current (softupdates, NFS) Message-ID: <19991129235631.P60031@bitbox.follo.net> In-Reply-To: <199911292152.NAA09656@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Nov 29, 1999 at 01:52:29PM -0800 References: <14399.63511.296802.242618@jabberwock.rstcorp.com> <19991127191729.A53832@bitbox.follo.net> <14402.62122.461010.454021@jabberwock.rstcorp.com> <199911292152.NAA09656@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 29, 1999 at 01:52:29PM -0800, Matthew Dillon wrote:
> :
> : Eivind> I *think* I know what this is due to - please upgrade
> : Eivind> src/sys/nfs/nfs_vnops.c to revision 1.146 (which I just
> : Eivind> committed) and try again.
> :
> :Tried it. Doesn't work. :-( It still crashes when creating a symbolic
> :link on a NFS mounted filesystem. [This is unfortunate in my case,
> :as it prevents me from running Netscape -- the home dirs are NFS
> :mounted]
>
> Eivind, I'm not sure that change you made is legal. People use
> symlink creation the same way they use O_EXCL file creation - as a
> locking mechanism. In fact, in NFSv2 O_EXCL file creation is not
> atomic (I'm pretty sure) and symlink was the *only* method available.
The sum of the changes I made does not (or is at least not supposed
to) change the semantics of symlink creation. If you see some way the
semantics are changed, please tell me - that's an error.
> If you blow away the error you will probably break a good deal of
> third party code.
I haven't added anything to blow away the error - I've moved code that
already was there up before code I added that depended on the error
being the same as what was returned.
I've been peering over the code, and I am unable to find anything
wrong :-( I've also gotten panic information and symbol information
from Viren, but this hasn't made me any wiser - the failure was in
setlock (which seems to be an assembler symbol related to
simplelock()), but this isn't of much help.
The only idea I have for a flaw right now is that if newvp in
nfs_symlink can somehow be NULL in the non-error case, then my code is
in error. The following patch adds a test for this:
Index: nfs/nfs_vnops.c
===================================================================
RCS file: /home/ncvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.146
diff -u -r1.146 nfs_vnops.c
--- nfs_vnops.c 1999/11/27 18:14:41 1.146
+++ nfs_vnops.c 1999/11/29 22:51:12
@@ -1821,8 +1821,10 @@
if (error) {
if (newvp)
vput(newvp);
- } else
+ } else {
+ KASSERT(newvp, ("No vp in nfs_symlink"));
*ap->a_vpp = newvp;
+ }
VTONFS(dvp)->n_flag |= NMODIFIED;
if (!wccflag)
VTONFS(dvp)->n_attrstamp = 0;
If somebody can run this and tell me if they get this panic instead of
the old one, I'd appreciate it.
Eivind, who thinks this might indicate he will have to set up an NFS
testing environment :-/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991129235631.P60031>