Date: Sat, 14 Mar 1998 09:53:27 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: michaelh@cet.co.jp (Michael Hancock) Cc: Tor.Egge@idi.ntnu.no, freebsd-current@FreeBSD.ORG Subject: Re: 4 WILLRELE's to bite the dust Message-ID: <199803140953.CAA19801@usr08.primenet.com> In-Reply-To: <Pine.SV4.3.95.980314142952.21881A-100000@parkplace.cet.co.jp> from "Michael Hancock" at Mar 14, 98 02:37:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I've been using nullfs since Nov 7 1997 without any serious problems
> > after having fixed some of the above mentioned problems in my local
> > source tree. The code is not perfect, panics are still possible due
> > to heuristics (due to VOP_ISLOCKED()) being wrong, but I've yet
> > not experienced any problems.
>
> What would you need to do to fix VOP_ISLOCKED()? Does it really make
> sense to have an VOP_ISLOCKED()? This ownership issue looks like a big
> can of worms.
Proxy the lock down with VOP_FINALVP.
Alternately, put the locking in common upper level code, and assume
it will be honored in the downpath, and move to veto-based VOP_LOCK.
I prefer the veto method, because it buys you some nice wins in
the fan-out/fan-in cases that would be difficult and costly to do
otherwise.
The vn_lock would assert the lock on the vp, and call the underlying
VOP_LOCK on the vp, and if it was veto'ed, back it out.
The coherency would be maintained by the stacking layer proxying the
lock to the covered vnode (the downcall is needed in NULLFS only
because it exposes the underlying FS multiple times in the namespace,
so you must explicitly maintain choherency; things like union FS
don't expose, so you could be sure that the underlying vp was
locked, in effect, by the upper level vp being locked).
The problem with the nullfs/nullfs mount (which *should* be permitted
to work, since a -> nullfs -> nullfs -> otherfs stack is a perfectly
reasonable thing to want to do so you can *avoid* exposing the stacked
upon FS) is that the real VOP_LOCK occurs twice on the same vp because
it's a real operation, not a proxy operation.
There are other coherency problems having to do with the backing vp's
associated VM object. John's recent changes allow aliases to work,
so in theory, a finalvp is not necessary; the problem here is what
gets marked dirty, however, so I have a hard time trusting anything
that does aliases, even if John's code appeared to "do the right thing".
My soloution would be to proxy the call to VOP_{GET|PUT}PAGES to the
real underlying VP, via the bypass mechanism, and disallow aliases
entirely.
You could do the same thing with a VOP_FINALVP (which is useful for
things other than locking, and not necessary in the veto implementation
for locks; the advisory locks want to get hung off the object with the
pages, and the vp's want to get locks if they get exposed anywhere in
the namespace, but probably not otherwise (except in the allocation
case, where they should be locked until they are pointed to by the
covering layer, and the covering layer's vp should be locked, after
which the covered layer can be unlocked (because it's ref'ed).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
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?199803140953.CAA19801>