Messages in this thread |  | | From | John Stultz <> | | Date | Mon, 4 May 2026 20:32:39 -0700 | | Subject | Re: [PATCH v2 1/2] sched: proxy-exec: Close race causing workqueue work being delayed |
| |
On Sun, May 3, 2026 at 10:37 PM K Prateek Nayak <kprateek.nayak@amd.com> wrote: > On 5/4/2026 12:12 AM, K Prateek Nayak wrote: > > So when looking at all of this, I realized we probably don't need > > PROXY_WAKING anymore if we have the "is_blocked" state in task_struct. > > The owner can simply clear the blocked_on and move along and the > > waiter's "is_blocked" state will handle the sched bits. > > > > (p->is_blocked && !p->blocked_on) can then be interpreted as > > PROXY_WAKING and that task should explore return migration in > > find_proxy_task(). > > > > Would something like below be more amenable from a backport standpoint > > instead of marking the config broken? > > > @@ -6535,8 +6548,10 @@ static bool try_to_block_task(struct rq *rq, struct task_struct *p, > * blocked on a mutex, and we want to keep it on the runqueue > * to be selectable for proxy-execution. > */ > - if (!should_block) > + if (!should_block) { > + sched_set_task_is_blocked(p); > return false; > + } >
So digging a bit more into this, it seems is_blocked in your patch is semantically different from what Peter was proposing.
Peter seemed to be suggesting is_blocked would be more generic then just for proxy-exec, getting set in try_to_block_task() regardless if we actually blocked the task or not, and then clearing it in ttwu_do_wakeup() when we go RUNNABLE. Pretty much independent of blocked_on.
Where as your patch is still having is_blocked very much tied with blocked_on (since with yours we only set is_blocked if we avoid blocking the task in try_to_block_task(), and clear it only from find_proxy_task()). In a way I can map your approach utilizing is_blocked as conceptually sort of separating the latch bit from my last approach, (if we also re-worked PROXY_WAKING to be the value 1 (!blocked_on + latch) instead of -1). So your approach seems workable (I've got it about half way integrated with my full series - hitting a little bit of trouble with the sleeping owner enquing at the moment), but I'm not sure this is what Peter is looking for.
thanks -john
|  |