[no subject]

> now, if we want to e.g. rename the whole group, we just start at 
> ncp_shadowroot and cycle through ncp_shadowlinks.

Renaming seems to be a truly individual act -- at least, I can't think
of any useable semantics for an operation like "group rename".

Moreover, renaming is not an atomic operation, it's the aggregate of
many smaller ones. We should concentrate on the critical ones of these.

AFAICS the critical one is breaking down the parent/child relation.  My
idea is that a p/c cut should imply breaking down shadower/shadowed
relatons. If we do that, the upper layer will see the lack of the link
into the lower one, and will recreate that as it's appropriate in the
new situation. The upper layer wouldn't be aware of the rename event in
the lower one as such.

> I don't know what matt thought of cache coherency because I don't know 
> the usage model, but what we are doing now at least does its job for 
> nullfs et al.

I hope so.

> how do you like this?

I see your proposals as optimizations (with not being convinced of their
necessity, but not being categorically against them). I think I can get
to not messing up the API and correct operation with small adjustments.
Implementing your ideas would take more effort. So let me just make my
adjustments, let's see if it works correctly, and if yes, then we can
return to discussing optimizations.

> the only thing that (still) bothers me is:   what happens if somebody 
> locks (cache_lookup) an unresolved (and thus unconnected) nullncp and 
> locks the shadowed ncp (where the system doesn't know about yet about 
> this connection).  imagine two processes doing this, each in different 
> order:
>
> time	thread1			thread2
> 1	lock null		lock lower
> 2	resolve null (blocks)	lock null (blocks)
>
> we have a deadlock.  resolving null means having to lock lower, but this 
> fails as another thread already obtained the lock.

Locking is a group operation. Therefore it must be group atomic -- eg.,
locking the group can't mean obtaining a lock (in the old sense) on each
entry simultaneously.

There must be one distinguished parameter in the group which carries
locked/unlocked state. In my approach it's the nc_exlocks field of the
group head. If a thread has that bumped, it has obtained the lock on the
whole group.

Regarding your example, thread2 won't perform a separate "lock null"
step.

Regards,
Csaba