From owner-cvs-sys  Tue Apr 15 05:57:04 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA07841
          for cvs-sys-outgoing; Tue, 15 Apr 1997 05:57:04 -0700 (PDT)
Received: (from kato@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA07824;
          Tue, 15 Apr 1997 05:57:01 -0700 (PDT)
Date: Tue, 15 Apr 1997 05:57:01 -0700 (PDT)
From: KATO Takenori <kato>
Message-Id: <199704151257.FAA07824@freefall.freebsd.org>
To: CVS-committers, cvs-all, cvs-sys
Subject: cvs commit:  src/sys/miscfs/union union_vnops.c
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

kato        97/04/15 05:57:00

  Modified:    sys/miscfs/union  union_vnops.c
  Log:
  Quick-hack to avoid `lock against myself' panic.  It is not the real
  fix!
  
  The ufs_link() assumes that vnode is not unlocked and tries to lock it
  in certain case.  Because union_link calls VOP_LINK after locking vnode,
  vn_lock in ufs_link causes above panic.
  
  Currently, I don't know the real fix for a locking violation in
  union_link, but I think it is important to avoid panic.
  
  A vnode is unlocked before calling VOP_LINK and is locked after it if
  the vnode is not union fs.  Even though panic went away, the process
  that access the union fs in which link was made will hang-up.
  
  Hang-up can be easily reproduced by following operation:
  
  	mount -t union a b
  	cd b
  	ln foo bar
  	ls
  
  Revision  Changes    Path
  1.24      +15 -2     src/sys/miscfs/union/union_vnops.c