On Fri, Nov 14, 2003 at 02:40:52PM -0500, Andrew Brown wrote:
> >> and then you have all the mappings for name<->number under net.  for
> >> the children of those nodes, you simply iterate.
> >
> >What happens if the name<->number mappings change in between the 
> >mapping call and the walking?  It's dynamic, so you're going to have to 
> >expect this.
> 
> good question.
> 
> the answer is that each node has a version number (an int -- i am
> studiously ignoring the case where the version number wraps around).
> 
> when a node is created the global version counter is incremented and
> the new version number is assigned to the new node and its parent,
> straight up to the root of the tree.
> 
> likewise, when a node is destroyed, the global version number is
> incremented, and the new version number is assigned to the parent of
> the node that is being destroyed all the way back up the tree.
> 
> sysctlnametomib() just checks that all the versions are the same at
> the top of the tree each time it's called, and for those that have
> changed, it purges that data from its cache.

It seems like sysctlnametomib() still races the kernel to lookup the
next name<->number mapping before the previous name<->number mapping
is changed/deleted.

It sounds like sysctlnametomib() can catch that by comparing the version
number at the top of the tree before the lookup with the version after
the lookup, and then either restart the lookup or return -1 (EBUSY?).
So far, so good.

Whether or not sysctlnametomib() restarts or returns -1 if an add/delete
invalidates the path, I am concerned that there is no guarantee that a
process will make any progress resolving any name if, say, the kernel
is rapidly adding/deleting nodes virtually anywhere in the tree. The
kernel might do that even in non-pathological cases.

I think I am probably just missing something.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933