--n1iI6MeELQa9IOaF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 06, 2007 at 03:02:00PM +0300, Antti Kantee wrote:
> On Thu Jul 05 2007 at 17:27:54 -0700, Bill Stouder-Studenmund wrote:
> > On Thu, Jul 05, 2007 at 11:50:38PM +0300, Antti Kantee wrote:
> > > On Thu Jul 05 2007 at 13:14:54 -0700, Bill Stouder-Studenmund wrote:
> > >=20
> > > Hmm, I thought had a very good reasoning for that, but I think I lost=
 it.
> > > Maybe I misreasoned.
> > >=20
> > > Anyway, the CURRENT state is that ONLY the lower vnode is being revok=
ed
> > > because of layer_bypass().  The upper is kind of implicitly getting
> > > revoked.  Maybe that should be changed to revoke only the upper one.
> >=20
> > For sys_revoke() processing, we want to revoke the lower one. That's th=
e=20
> > only way we can destroy all instances of the device and all access path=
s.
>=20
> Right.  That was my reason.
>=20
> Although, the description on the manual page (revoke(2)) is a bit wrong:
> The revoke function invalidates all current open file descriptors in
> the system for the file named by path.
>=20
> It doesn't take aliasing into account.

It should. It's why we have device aliases, so if you revoke one you=20
revoke them all.

> > > Well, revoke is "check for device aliases + reclaim regardless of
> > > use count".  A forced unmount is "reclaim regardless of use count".
> > > I was just talking from the perspective of reclaim, once again.
> >=20
> > It's different w.r.t. layering. unmount wants to do the top of a stack,=
=20
> > sys_revoke() wants to do the root.
>=20
> No, it's not.  Forcibly unmount the root layer.  I am still talking
> about *reclaim*, not revoke.  I am talking about reclaim because the
> reclaim introduced by revoke is the one causing problems.  If you just
> give revoke special treatment, the unmount -f problem remains.

True. Ok.

> > The problem I see is that there's no easy way (that I can see) of makin=
g=20
> > this extend to all the layering we can have now. What about a stack lik=
e:
> >=20
> >         A    B
> >          \ /
> >           C   D
> >            \ /
> >             L
> >=20
> > Where A, B, C, and D are different layer mounts, and L is the leaf file=
=20
> > system under it all.
> >=20
> > Say D processes the revoke, or say it happens directly on L. C and D ca=
n=20
> > notice that something changed underneath, but A and B can't easily noti=
ce=20
> > a change to L, since they'd only see it if C changed somehow.
>=20
> My head just exploded.  Call me silly, but I'd be happy if a stack like
> this worked for starters:
>=20
>          A
>          |
>          B

It should. However we shouldn't make a fix that only works for this.

> Seriously though, that's what I was talking about when I said recursing
> to the bottom.  Instead of caching a lock pointer in each layer node,
> traverse to the bottom or until a defunct lock is found and act as if
> a lock wasn't exported.

That would be another option. If we can fix it otherwise, I'd rather do=20
that. But if we have to do this, we will.

Take care,

Bill

--n1iI6MeELQa9IOaF
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFGjo3gWz+3JHUci9cRAoA+AJ9DIlpZ9z2RIM09nOs+vHa2ub1KkACgmBbM
Dirs+3uuOax+1LU0rzj5ufY=
=5tSx
-----END PGP SIGNATURE-----

--n1iI6MeELQa9IOaF--