Re: [PATCH v2] sched/proxy_exec: Break cyclic proxy chains by deactivating blocked tasks

[K Prateek Nayak]

Hello Zhidao,

On 7/15/2026 8:07 AM, soolaugust@xxxxxxxxx wrote:
> Thanks Prateek.
> 
>> I'm not really a fan of the arbitrary MAX_PROXY_CHAIN_DEPTH.
> 
> Agreed. It was only a guard rail, not a real fix. I'll drop it in v3
> and switch to a proper cycle check.
> 
>> This only catches cycles that come back to the original donor.
> 
> Right. The owner == donor check only catches cycles that include the
> original donor, so it misses loops in the middle of the chain, like
> your A -> B -> C -> D -> B example.
> 
>> Maybe we can use the blocked_donor backlink as a visited marker?
> 
> The basic idea makes sense, but I'd rather not overload blocked_donor.
> That field is already the donor-stack backlink, and keeping it as a
> plain task pointer seems easier to reason about as the proxy-exec model
> grows to more primitives.
> 
> So for v3 I'll likely use an explicit per-pick seq marker instead.

Ack! Sample code was just a PoC to see if it is good enough to solve the
hard lockup problem :-)

Btw, I realized you'll need to reset this marker on migration, else
there is a rare chance of a stale p->blocked_donor pick_seq from an old
pick CPU colliding with the pick_seq after migration.

For my PoC, this was a good enough solution:

diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 452cbcd3a8c5..f5180913c038 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2400,6 +2400,7 @@ static inline void __set_task_cpu(struct task_struct *p, unsigned int cpu)
 	smp_wmb();
 	WRITE_ONCE(task_thread_info(p)->cpu, cpu);
 	p->wake_cpu = cpu;
+	p->blocked_donor = NULL;
 	rseq_sched_set_ids_changed(p);
 #endif /* CONFIG_SMP */
 }
---

You can make this fit as per your v3 scheme.

>> We should probably think about other lock types too.
> 
> Yes, agreed. That's another reason to keep this at the proxy
> wait-for-chain level rather than make it mutex-specific. The current
> tree still only has mutex-backed blocked_on, but the design is meant to
> cover other blocking primitives as well.

Ack! I think eventually, blocked_on becomes a struct with a lock_type
enum + void* pointer which allows for interpreting the pointer based
on the lock_type.

I agree p->blocked_donor has other uses with the extended series so it
is best to use a separate variable to track the seq_count if we go down
that route.

I'll let John comment if it is a good idea or not.

> 
> Thanks for the review. I'll rework v3 accordingly.

Thanks a ton.

-- 
Thanks and Regards,
Prateek