Re: [PATCH] hazptr: handle NULL address in hazptr_detach

[Mathieu Desnoyers]

On 2026-09-08 12:22, Paul E. McKenney wrote:
> On Tue, Sep 08, 2026 at 11:29:31AM -0400, Mathieu Desnoyers wrote:
> > On 2026-09-08 11:24, Bradley Morgan wrote:
> > > On 8 September 2026 16:22:14 BST, Mathieu Desnoyers
> > > <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
> > > > When hazptr_acquire loads a NULL pointer, it sets:
> > > >
> > > > - slot_item->slot.addr = NULL,
> > > > - slot_item->ctx.ctx = ctx
> > > > - ctx->slot = slot
> > > >
> > > > And it returns NULL.
> > > >
> > > > Then hazptr_detach is called on this ctx, it will act on the ctx as if
> > > > needed to be promoted to backup slot, even though it has a NULL addr.
> > > >
> > > > Looking at what hazptr_note_context_switch() does before promoting
> > > > to backup slot, it checks for a NULL slot->addr, which is exactly
> > > > what is missing from hazptr_detach.
> > > >
> > > > With this in place there would be no need to explicitly check the
> > > > hazptr_acquire() return value before calling hazptr_detach().
> > > >
> > > > hazptr_release() has a early return check for NULL addr as well, so it
> > > > makes sense that detach does an early return (no-op) similarly.
> > >
> > > You shall kill me for this!!
> > >
> > > Could you perhaps do a splat in ze commit description pls?
> >
> > The splat is available at the "Closes" URL below. I'm not sure whether
> > we should duplicate this verbose information ?
> >
> > Paul ?
>
> I am fine either way, as long as the information is reasonably easily
> accessible.  Which is the case either way.  ;-)

Then I favor a concise commit message, leaving the splat details to the
"Closes" link. Feel free to pick up this patch for testing.

Thank you!

Mathieu


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