hazptr_synchronize() cost

Thanks for the response!

Thinking about this comment:

> I suspect that once you can afford atomics on a global variable on the read-side, you already have a solution available: reference counting

I don't think atomics are the only reason to avoid a refcount. Another is memory space in the relevant data structure. There are probably others.

One use case I'm thinking of is in fs/namespace.c where namespace_unlock() calls synchronize_rcu_expedited().
I think this is to wait for __legitimize_mnt() to complete, and importantly for the "mnt_add_count(mnt, -1);" to run if needed.

If namespace_unlock() proceeds past the synchronize_rcu_expedited() too soon, the mntput() call might find that the refcount is still temporarily elevated, and it won't wait. Which would be bad.

If __legitimize_mnt() calls hazptr_acquire(mnt) before incrementing, and hazptr_release(mnt) before it returns, then namespace_unlock() could call hazptr_synchronize() on each mnt before calling mntput.
I don't think this rcu / hazptr usage is really about avoiding atomics (there are various atomics in that function). It is about finding the most economical way to close a gap.
And I wonder how the cost of an atomic compares with the cost of scanning a large array when there is a large number of CPUs. I really don't know the answer there.

BTW, I imagine that an even simpler solution to the fs/namespace.c race is to call hazptr_acquire(foo) where "foo" is some constant that no other code would use, maybe the address of some function. Then namespace_unlock() could call hazptr_synchronize(foo) just once (rather than once per mnt). That could be cheaper in the cases where there were multiple mnts (which I think can happen, but maybe not often). The one hazptr_synchronize() call could wait for all running __legitimize_mnt() calls (like synchromnize_rcu_expedited() does - but it waits for lots of other stuff too).

Is there any reason that might not work? i.e. using an abstract pointer rather than a pointer to the particular memory we want to monitor.

One thing I really like about hazptr is it forces you to document in the code exactly what you are waiting for. With RCU it is a bit like the old BKL in that you really need to understand the code to be able to see what is protected.