Re: [RFC PATCH v5 1/2] hazptr: Implement Hazard Pointers

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-07-08 18:55, Paul E. McKenney wrote:
[...]
> OK, I did check, and all of the hazptr_torture_do_pending() function's
> hazard pointers have been passed to hazptr_detach_from_task().
> 
> But sometimes a given hazard pointer might be passed to
> hazptr_detach_from_task() twice, once just before that llist_add(),
> and again if hazptr_torture_reader_tail() decides to release that hazard
> pointer via smp_call_function_single().
> 
> Do I instead need to be careful to avoid detaching a given hazard pointer
> more than once?
That should be OK to call the "detach" more than once, because it checks
if the hazptr is already detached with:

+       if (unlikely(hazptr_slot_is_backup(ctx, slot)))
+               return;

(while under preempt off)

My concern is about this worker thread:

static int hazptr_torture_do_pending(void *arg)
{
         int cpu = 0;
         DEFINE_TORTURE_RANDOM(rand);

         VERBOSE_TOROUT_STRING("hazptr_torture_do_pending task started");
         do {
                 if (stutter_will_wait()) {
                         for_each_possible_cpu(cpu)
                                 hazptr_torture_do_one_pending(cpu, &rand);
                 } else {
                         cpu = cpumask_next_wrap(cpu, cpu_possible_mask);
                         hazptr_torture_do_one_pending(cpu, &rand);
                 }
                 if (torture_must_stop())
                         torture_hrtimeout_ms(kthread_do_pending_ms, USEC_PER_MSEC, &rand);
                 // Omit stutter_wait() because this function needs to do cleanup.
         } while (!torture_must_stop());
         torture_kthread_stopping("hazptr_torture_do_pending");
         return 0;
}

which as you will notice happily invoke "do_one_pending" on either
all possible cpus or on a next cpu (non-local), which does:

         llhp = per_cpu_ptr(&hazptr_pending, cpu);
         llnp = llist_del_all(llhp);
         if (!llnp)
                 return;
         llist_for_each_entry_safe(hppp, hppp1, llnp, hpp_node) {
                 hazptr_torture_reader_tail(hppp, trsp);
                 atomic_long_inc(per_cpu_ptr(&hazptr_torture_releases_undefer,
                                             raw_smp_processor_id()));
                 kfree(hppp);
         }

And here the reader_tail calls cur_ops->readunlock(hcp, htp); which
does a hazptr_release from the wrong CPU without previously detaching
the hazptr from its associated thread as it should.

Does this line of thinking make sense ?

Thanks,

Mathieu

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