On 2026-06-27 08:56, Mathieu Desnoyers wrote:
> On 2026-06-27 00:14, Paul E. McKenney wrote:
>> On Fri, Jun 26, 2026 at 11:56:13PM -0400, Mathieu Desnoyers wrote:
>>> On 2026-06-26 19:06, Paul E. McKenney wrote:
> [...]
>>>> Initial runs suggest that hazard pointers cannot be acquired by one
>>>> task and released by another.  Is that expected behavior, or is my test
>>>> improperly passing the hazard pointers?  If the latter, we should of
>>>> course document the proper hazard-pointer-passing mechanism.
>>>
>>> This is unexpected. I've looked at your test code quickly and could
>>> not figure out what's wrong though. But it's late. How do you observe
>>> that it fails ?
>>
>> Not an emergency, so your schedule is my schedule.  Especially given
>> that I am mostly taking this coming week off.  And that it took me such
>> a long time to get this torture test done.  ;-)
>>
>> I run either scenario (PREEMPT or NOPREEMPT) with:
>>
>> --bootarg "hazptrtorture.onoff_interval=3333 
>> hazptrtorture.stat_interval=15"
>>
>> I get the following on the console, and things go downhill from there.
>> I get the same thing when I turn off CPU hotplug, for whatever that is
>> worth.
> That OOPS is very instructive. I think I found the root cause.
> 
> I need to add an API to hazptr so users wishing to explicitly transfer
> ownership of the hazptr ctx to another thread can do so.
> 
> Currently the scheduler hook is responsible for moving the hazptr
> ctx from per-cpu to the backup slots, which makes it entirely movable
> afterwards.
> 
> But this assumes the ctx is thread-local. Once you explicitly move
> ownership of that ctx to another thread, you race with the scheduler of
> the original thread.
> 
> Let me see what I can do to fix that.
> 
> Thanks a lot for the test-case !

Can you try with the attached POC diff ?

Thanks,

Mathieu

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