> > for example,
> > 
> > int
> > vn_remove(const char *path)
> > {
> > 
> > 	lookup_parent(..., &dvp, ...);
> > 
> > 	vngate_enter(dvp->v_mount);
> > 	lock(dvp);
> > 	lookup_lastcomponent(dvp, &vp, ..);
> > 	VOP_REMOVE(dvp, vp, ...);
> > 	vngate_leave(dvp->v_mount);
> > }
> 
> Why do you think "lookup_parent()" does not change file system data/metadata?

lookup_parent does its own vngate_enter/leave dance.

each path components can belong to different filesystems than dvp
and i want to avoid to do vngate_enter multiple filesystems simultaneously.

> What if we make lookup() gate-aware?
> 
> 	- add struct mount *ni_gate, *ni_dgate to struct nameidata
> 	- add an option KEEPGATES to namei() so namei() either leaves
> 	  the gates on return or keeps them if KEEPGATES is given.

i hesitate to complicate namei, which is already too complex...

besides, it's desirable to have enter/leave in the same function
if possible, IMO.  if we take the route, it's better to hide vngate_leave
into, say, namei_done().

> and this becomes
> 
> 	NDINIT(..., KEEPGATES, ...)
> 	namei(&nd);
> 	VOP_LEASE(...)
> 	...
> 	VOP_REMOVE(nd.ni_dvp, nd.ni_vp, ...);
> 	vngate_leave(nd.ni_dvp->v_mount);
> 	vngate_leave(nd.ni_vp->v_mount);

i think it's better not to take the gate multiple times.

> > > > - why does it need the special care?
> > > 
> > > It solves a real problem now that may go away with updates to the softdep code
> > > or the introduction of a real i/o scheduler.
> > 
> > it isn't clear to me why the suspension on filesystem A has a priority over
> > activities on unrelated filesystem B.
> 
> Try it for yourself (on one disk if you need real problems)....

for what?  to see how it's slow?

YAMAMOTO Takashi