Re: [PATCH 2/2] hazptr: Introduce CONFIG_HAZPTR_DEBUG misuse detection

[Paul E. McKenney]

On Tue, Jul 14, 2026 at 05:06:37PM -0400, Mathieu Desnoyers wrote:
> On 2026-07-14 16:54, Paul E. McKenney wrote:
> [...]
> > > > > AFAIU there is partial overlap between refcount, hazptr, and RCU, each
> > > > > with their own strengths and weaknesses. We should prepare a summary
> > > > > table for the end users wondering which is the right tool for their
> > > > > use-case.
> > > > 
> > > > We have lots of such tables of varying sizes and levels of detail in
> > > > numerous C++ Working Papers, to say nothing of Section 9.6 of perfbook.  ;-)
> > > > 
> > > > One short text distinguishing them is: "RCU is a fast and scalable
> > > > replacement for many reader-writer locking use cases, hazard pointers is
> > > > a fast and scalable replacement for many reference-counting use cases,
> > > > reader-writer locking provides mutual exclusion, and reference counting
> > > > provides instant notice when the counter reaches zero."
> > > 
> > > lgtm
> > 
> > Fair enough!  Put this in Documentation/RCU?  As a header comment in
> > include/linux/hazptr.h?  Somewhere else?
> > 
> 
> I'm tempted to add the documentation into Documentation/RCU and a
> reference to it in the RCU, hazptr, and refcount headers so people
> stumbling on one of those three can be pointed to the higher level
> document which explains how each relate to one another.
> 
> But is referencing documentation from code even something we typically
> do ?
> 
> Also given this would discuss more than just RCU, I'm not sure Doc/RCU
> is the right home for it, but we don't have a Documentation/existence
> nor Documentation/synchronization. Thoughts ?

Rename kernel/rcu to kernel/defer and Documentation/RCU to
Documentation/defer?  I am sure that this would not be at all
disruptive.  ;-)

							Thanx, Paul