> On Dec 14, 2025, at 10:43 PM, Mathieu Desnoyers
> <[email protected]> wrote:
>
> On 2025-12-14 02:14, Joel Fernandes wrote:
> [...]
>>> We have had similar issues with kfree_rcu() and running out of preallocated
>>> memory there meant we just triggered a slow path (synchronize) but for
>>> hazard ptr I am not sure what such a slow path would be since, since this
>>> problem appears to be on the reader side.
>>>
>>> Perhaps we can also pre allocate overflow nodes in the api itself, and tap
>>> into that in case of overflow? The user need not provide their own storage
>>> then for overflow purposes, I think. And perhaps this pre allocated pool of
>>> overflow nodes can also be common to all hazptr users. Ideally it would be
>>> good to not all the api user deal with overflow at all and it transparently
>>> works behind the scenes.
>
> With the preallocation approach, how can we guarantee that we
> preallocate enough, and if we cannot provide that guarantee,
> how should readers behave when they reach that limit ?
Sure, see below.
>>>
>>> I think we need not worry too much about cases of preallocated overflow
>>> nodes itself running out because that is no different than reserved memory
>>> needed in atomic context which need a minimum off anyway right? And we have
>>> a bounded number of CPU and bounded number of context, so the number of
>>> *active* nodes required at any given time should also be bounded?
>
> So the "simple" implementation presented by Boqun at LPC2025 was limited
> to preemption disabled context, but in general there is really no need
> to require hazptr users to disable preemption for the entire duration of
> their hazptr protected critical section. This means that tasks holding a
> hazptr can be preempted or blocked, which increases significantly the
> number of concurrently active hazptr we need to preallocate.
>
> So I'd rather remove the preempt disable constraint across the entire
> hazptr crtitical section if it's not too much trouble. And it appears
> that backup slots preallocation is the only fundamental reason that
> would motivate this constraint so far.
We can remove the preempt disable constraint and still not require stack
allocation by simply embedding overflow nodes and any other context, in
task_struct right? This is similiar to how preemptible-rcu tracks readers.
>> ... By the way I wanted to emphasize my PoV, that requiring storage provided
>> by the user seems to negate one of the big benefits of hazard pointers I
>> think. Unless there is a solid use case for it, we should probably not
>> require the user to provide separate storage IMHO (or make allocation
>> internal to the api as I mentioned).
> I think the solution I have in mind takes care of the negative aspects
> of preallocation requirement. Here is how it would be used (see
> [1] for the current prototype). The "backup slot" is within the
> struct hazptr_ctx, so from a user perspective, it's under the hood.
>
> The user just has to provide a context variable on its stack.
>
> (untested example below)
>
> void *ptr;
>
> void fct(void)
> {
> struct hazptr_ctx ctx;
> void *addr;
>
> addr = hazptr_load_try_protect(&ctx, &ptr);
> if (!addr)
> return;
> [critical section]
> hazptr_release(&ctx, addr);
Correct me if I am wrong but I am not seeing why stack ctx is required if ctx
and any space required can be placed in the task struct (and hidden from the
user). For interrupts, we can just use per cpu storage split by context like
qspinlock does, I think (unless we are going with the wild card proposals).
Thoughts?
Thanks.
