From mika@obelix.cs.caltech.edu  Wed Apr  1 03:13:36 1998
Received: from vlsi.cs.caltech.edu (vlsi.cs.caltech.edu [131.215.131.129])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA05881
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 1 Apr 1998 03:13:35 -0800 (PST)
          (envelope-from mika@obelix.cs.caltech.edu)
Received: from obelix.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1)
	id AA10804; Wed, 1 Apr 98 03:13:34 PST
Received: (from mika@localhost)
	by obelix.cs.caltech.edu (8.8.8/8.8.7) id DAA12444;
	Wed, 1 Apr 1998 03:13:33 -0800 (PST)
Message-Id: <199804011113.DAA12444@obelix.cs.caltech.edu>
Date: Wed, 1 Apr 1998 03:13:33 -0800 (PST)
From: Mika Nystrom <mika@cs.caltech.edu>
Reply-To: mika@cs.caltech.edu
To: FreeBSD-gnats-submit@freebsd.org
Subject: VFS cache confuses the kernel when using amd (VFS cache is broken)
X-Send-Pr-Version: 3.2

>Number:         6189
>Category:       kern
>Synopsis:       VFS cache confuses the kernel when using amd (VFS cache is broken)
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Apr  1 03:20:00 PST 1998
>Closed-Date:    Mon Apr 6 23:12:35 PDT 1998
>Last-Modified:  Mon Apr  6 23:13:02 PDT 1998
>Originator:     Mika Nystrom
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
California Institute of Technology
>Environment:

Dual PPro 3.0-CURRENT SMP system.  Earlier tests indicate problem is
not isolated to the SMP universe.  Misreported as an amd problem due
to insufficient debugging.
>Description:

We are heavy users of (amd-)automounted filesystems.  We use the directory
/ufs as the "home" for amd and use /tmp_mnt for the mountpoints.  To
refresh your memory, as far as I understand, the way amd works is like
this.. let me take an example.. my mail spool is /ufs/mail/mika, when
I examine it, the following takes place:

kernel asks amd (which is masquerading as an NFS server) about /ufs/mail/mika,
gets returned something that tells it there's a symlink from 
/ufs/mail to /tmp_mnt/vlsi/var/spool/mail (which has by now been
automounted) and then does whatever to the file 
/tmp_mnt/vlsi/var/spool/mail/mika.  The problem seems to be that
the symlink /ufs/mail is somehow cached by the kernel after amd has
decided to umount the system, causing the system to try to look up
a nonexistent file.  To verify the problem, I ran the following
repeatedly:

amq -u /ufs/mail ; ./a.out

where a.out was compiled from:

#include <sys/stat.h>
#include <sys/types.h>

struct stat sb;

main()
{
  printf("%d\n",stat("/ufs/mail/mika",&sb));
}

When run repeatedly, this command line alternates a zero output
(success) with many -1 outputs (failure).  Running amd in full
debug mode and running ktrace on amd shows that in the -1 cases,
1. amd does not output any debugging information (even at the
highest debug level) and 2. amd does not do anything caught by
ktrace (kdump.out does not grow).  This indicates that the kernel
is doing something Wrong, caching the symlink.  This was verified
by setting debug.vfscache to 0 through sysctl, after which amd
automounts appear to work perfectly.

>How-To-Repeat:

See above.
>Fix:
	
Quick workaround: sysctl -w -n debug.vfscache=0
Proper fix: unknown, but has something to do with the vfscache! (I
suppose it is possible amd is misbehaving somehow, confusing
the caching functions...)

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: jkh 
State-Changed-When: Mon Apr 6 17:27:58 PDT 1998 
State-Changed-Why:  
This PR is superceded by PR#6231 
State-Changed-From-To: closed->open 
State-Changed-By: jkh 
State-Changed-When: Mon Apr 6 22:29:15 PDT 1998 
State-Changed-Why:  
Author notes that this problem is actually still open. 
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Mon Apr 6 23:12:35 PDT 1998 
State-Changed-Why:  
see pr 6231 for the sequel. 
>Unformatted:
