Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Oct 2001 06:28:14 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Jonathan Lemon <jlemon@flugsvamp.com>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, Jun Kuriyama <kuriyama@imgsrc.co.jp>, David Wolfskill <david@catwhisker.org>, Current <FreeBSD-current@FreeBSD.ORG>
Subject:   Re: panic: vrele: missed vn_close
Message-ID:  <20011025060816.S73743-100000@delplex.bde.org>
In-Reply-To: <20011024135503.C75389@prism.flugsvamp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Oct 2001, Jonathan Lemon wrote:

> Hmm.  The way the revamped console code works is this:
>
>   cn_devopen() calls vn_open() to open the device.  If this is not a
> VCHR device, then it is closed.  Otherwise, the vnode is stashed in
> cnd->cnd_vp.
>
>   When the device is closed though cnclose(), it walks through a list
> of console devices, and if cnd_vp != NULL, calls vn_close() for that
> vnode, and then NULLs out cnd_vp. (drops the reference.)
>
>   My understanding is that vn_open/vn_close will track the count of
> outstanding references to the vnode, so this should be safe to do.

The reference counts were inadequate for handling controlling terminals
in the old version.  I don't see how this can work now.  You do extra
opens.  This will prevent controlling ttys going away properly.  E.g.,
suppose sio0 is a console device and is completely closed.  The following
sequence of operations should leave it a non-controlling tty:

				sio0's ref count
	open sio0		1
	make sio0 a ctty	2
	open cn			3
	close sio0		2
	lose sio0 as a ctty	1

sioclose() will not be called here since the reference count is > 0,
so ctty-related stuff in its tty struct will not be cleared, and things
break.

Similarly with sio0 and cn reversed.

The old code had kludges to handle one of these cases.  I had fixes
for the other one.  These are now invalid (sigh).  I didn't commit
them because there seemed to be a lot of races nearby.  Perhaps the
panic is caused a race.  The races are related to stashing of pointers
related to controlling terminals.  The lifetime of these pointers is
unclear.

Bruce


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?20011025060816.S73743-100000>