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

[Mathieu Desnoyers]

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