From owner-cvs-sys  Tue Apr 15 22:56:48 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id WAA12108
          for cvs-sys-outgoing; Tue, 15 Apr 1997 22:56:48 -0700 (PDT)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA12086;
          Tue, 15 Apr 1997 22:56:26 -0700 (PDT)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id FAA13801; Wed, 16 Apr 1997 05:56:21 GMT
Date: Wed, 16 Apr 1997 14:56:21 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
To: KATO Takenori <kato@freefall.freebsd.org>
cc: CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org,
        cvs-sys@freefall.freebsd.org
Subject: Re: cvs commit:  src/sys/miscfs/union union_vnops.c
In-Reply-To: <199704151257.FAA07824@freefall.freebsd.org>
Message-ID: <Pine.SV4.3.95.970416144928.13445B-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

I saw that you found the real fix later.  Cool. 

Regarding the below, I think it's better to panic in this case.  Making
things robust often works against making it work correctly.  Consistency
checks that result in panics are there to help you find problems.  Working
around consistency checks usually results in crufty code.

Just my opinion.

Regards,


Mike Hancock

On Tue, 15 Apr 1997, KATO Takenori wrote:

> 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
>