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

[Mathieu Desnoyers]

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 :)

> > > + */
> > >    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!

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

Thanks!

Mathieu

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