From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: paulmck@kernel.org
Cc: Boqun Feng <boqun@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] hazptr: Introduce CONFIG_HAZPTR_DEBUG misuse detection
Date: Sat, 11 Jul 2026 09:48:18 -0400 [thread overview]
Message-ID: <8179f07b-e6c5-4e77-869d-a5cbb0201662@efficios.com> (raw)
In-Reply-To: <7394f8f9-7b49-4d8a-8a24-c1074f4242be@paulmck-laptop>
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.
[...]
>
> +/**
> + * hazptr_detach_from_task - Allow a hazard pointer to be released by some other task
> + *
> + * @ctx: The hazard-pointer context to be migrated.
> + *
> + * By default, a given hazptr_acquire() and the corresponding
> + * hazptr_release() must run in a single execution context, for example,
> + * the context of a single task or a single interrupt handler. When you
> + * have acquired a hazard pointer in one context and need to release it
> + * in another, you must invoke hazptr_detach_from_task() on that hazard
> + * pointer's context. It is permissible to invoke hazptr_detach_from_task()
> + * multiple times on the same @ctx while it is protecting the same pointer,
> + * however, the first invocation absolutely must be in the same context
> + * that did the hazptr_acquire(), and must take place after the return
> + * from that hazptr_acquire().
> + *
> + * For example, if a hazard pointer is acquired by a task and
> + * released by a timer handler, that task would need to pass the hazard
> + * pointer's context to hazptr_detach_from_task() after return from the
> + * hazptr_acquire() and before arming the timer (or at least before the
> + * handler had a chance to access that hazard-pointer context).
good.
> + */
> 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 ?
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.
> + *
> + * By default, the call to hazptr_release() must be running in the same
> + * execution context as the corresponding hazptr_acquire(), for example,
> + * within the same task or interrupt handler. When it is necessary
> + * to instead call hazptr_release() from some other context, pass @ctx
> + * to hazptr_detach_from_task() in the original context after invoking
> + * hazptr_acquire() but before making the hazard pointer available to that
> + * other context.
> + *
> + * It is not permissible to invoke hazptr_acquire() twice on the same @ctx
> + * without an intervening hazptr_release().
good
> *
> * Returns a non-NULL protected address if the loaded pointer is non-NULL.
> * Returns NULL if the loaded pointer is NULL.
> @@ -233,7 +269,23 @@ void hazptr_release_debug(struct hazptr_ctx *ctx, void *addr)
> static inline void hazptr_release_debug(struct hazptr_ctx *ctx, void *addr) { }
> #endif
>
> -/* Release the protected hazard pointer from @slot. */
> +/**
> + * hazptr_release - Release the specified hazard pointer
> + *
> + * @ctx: The hazard-pointer context that was passed to hazptr_acquire().
> + * @addr_p: The pointer that is to be hazard-pointer unprotected.
> + *
> + * Release the protected hazard pointer recorded in @ctx.
> + *
> + * By default, hazptr_release() must execute in the same execution context
> + * that invoked the corresponding hazptr_acquire(), for example, within the
> + * same task or the same interrupt handler. However, if this restriction
> + * is problematic for your use case, please see hazptr_detach_from_task().
> + *
> + * It is permissible (though unwise from a maintainability viewpoint)
> + * to invoke hazptr_release() twice on the same @ctx without an intervening
> + * hazptr_acquire().
Good!
Thanks,
Mathieu
> + */
> static inline
> void hazptr_release(struct hazptr_ctx *ctx, void *addr)
> {
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
next prev parent reply other threads:[~2026-07-11 13:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 18:29 [PATCH 1/2] hazptrtorture: Fix hazptr ownership issue Mathieu Desnoyers
2026-07-09 18:29 ` [PATCH 2/2] hazptr: Introduce CONFIG_HAZPTR_DEBUG misuse detection Mathieu Desnoyers
2026-07-09 18:47 ` Paul E. McKenney
2026-07-09 18:56 ` Mathieu Desnoyers
2026-07-09 20:44 ` Paul E. McKenney
2026-07-09 21:47 ` Mathieu Desnoyers
2026-07-09 23:05 ` Paul E. McKenney
2026-07-09 23:22 ` Mathieu Desnoyers
2026-07-09 23:48 ` Paul E. McKenney
2026-07-10 0:10 ` Mathieu Desnoyers
2026-07-10 19:07 ` Paul E. McKenney
2026-07-11 13:48 ` Mathieu Desnoyers [this message]
2026-07-11 23:55 ` Paul E. McKenney
2026-07-14 19:16 ` Mathieu Desnoyers
2026-07-14 20:54 ` Paul E. McKenney
2026-07-14 21:06 ` Mathieu Desnoyers
2026-07-14 21:31 ` Paul E. McKenney
2026-07-09 23:57 ` Boqun Feng
2026-07-10 0:03 ` Mathieu Desnoyers
2026-07-09 20:45 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8179f07b-e6c5-4e77-869d-a5cbb0201662@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=boqun@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome