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

[Paul E. McKenney]

On Tue, Jul 14, 2026 at 03:16:58PM -0400, Mathieu Desnoyers wrote:
> On 2026-07-11 19:55, Paul E. McKenney wrote:
> > On Sat, Jul 11, 2026 at 09:48:18AM -0400, Mathieu Desnoyers wrote:
> > > On 2026-07-10 15:07, Paul E. McKenney wrote:
> > > > > 
> > > > > We should really rename this given that it detaches the hazptr ctx from
> > > > > the execution _context_ (irq handler or thread). Not sure how to name it
> > > > > though.
> > > > 
> > > > hazptr_detach_from_context()?
> > > > 
> > > > I am leaving this alone for the moment, easy to change later.
> > > 
> > > I just wonder if that name brings confusion. Is "context" the
> > > execution context or the "hazptr ctx" context ? I fear this is
> > > really a good opportunity to confuse everyone.
> > > 
> > > [...]
> > > 
> > > > 
> > > > > Maybe just call it hazptr_detach() ?
> > > > 
> > > > That would be your choice, not mine.  ;-)
> > > 
> > > I find that hazptr_detach is probably better here. It does not
> > > state it detaches "what", but at least there is no shortcut
> > > confusion with the overloaded "context" wording.
> > 
> > Fair enough.
> > 
> > Would you like me to make this change?
> 
> Since you're actively working in that area, please go ahead :)

OK, rebasing.  ;-)

> > > > + */
> > > >    static inline
> > > >    void hazptr_detach_from_task(struct hazptr_ctx *ctx)
> > > >    {
> > > > @@ -160,12 +182,26 @@ void hazptr_note_context_switch(void)
> > > >    	}
> > > >    }
> > > > -/*
> > > > - * hazptr_acquire: Load pointer at address and protect with hazard pointer.
> > > > +/**
> > > > + * hazptr_acquire - Load pointer at address and protect with hazard pointer.
> > > > + *
> > > > + * @ctx: The hazard-pointer context to be passed to hazptr_release().
> > > > + * @addr_p: Pointer to the pointer that is to be hazard-pointer protected.
> > > >     *
> > > >     * Load @addr_p, and protect the loaded pointer with hazard pointer.
> > > > - * When using hazptr_acquire from interrupt handlers, the acquired slots
> > > > - * need to be released before returning from the interrupt handler.
> > > > + * This protection is roughly similar to that of a reference counter, and
> > > > + * ends with a later call to hazptr_release().
> > > 
> > > Perhaps worthwhile to hint at the vast performance/scalability/memory
> > > footprint/cache line footprint difference between hazptr and refcount
> > > to justify why both exist here ?
> > 
> > Like this?
> > 
> >   * Load @addr_p, and protect the loaded pointer with hazard pointer.
> >   * This protection is roughly similar to (but way faster than) that of a
> >   * reference counter, and ends with a later call to hazptr_release()
> 
> works for me!

Got it, thank you!

> > > 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?

							Thanx, Paul

> Thanks!
> 
> Mathieu
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com