From owner-cvs-sys  Wed Apr 16 01:52:10 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id BAA04044
          for cvs-sys-outgoing; Wed, 16 Apr 1997 01:52:10 -0700 (PDT)
Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA03950;
          Wed, 16 Apr 1997 01:51:32 -0700 (PDT)
Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id SAA09685; Wed, 16 Apr 1997 18:51:15 +1000
From: Darren Reed <darrenr@cyber.com.au>
Message-Id: <199704160851.SAA09685@plum.cyber.com.au>
Subject: Re: cvs commit:  src/sys/miscfs/union union_vnops.c
To: michaelh@cet.co.jp (Michael Hancock)
Date: Wed, 16 Apr 1997 18:51:15 +1000 (EST)
Cc: kato@freefall.freebsd.org, CVS-committers@freefall.freebsd.org,
        cvs-all@freefall.freebsd.org, cvs-sys@freefall.freebsd.org
In-Reply-To: <Pine.SV4.3.95.970416144928.13445B-100000@parkplace.cet.co.jp> from "Michael Hancock" at Apr 16, 97 02:56:21 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

In some mail I received from Michael Hancock, sie wrote
> 
> 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.

A system that is up is a good thing.

If a systems admin. can crash it by typing a mount command (for example)
incorrectly, that is bad (IMHO).  I see what you're getting at but I'd
prefer it to return a nasty error.

Darren

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