Messages in this thread | | | Subject | Re: [RFC][PATCH 03/16] sched: Wrap rq::lock access | From | Tim Chen <> | Date | Fri, 22 Mar 2019 16:44:22 -0700 |
| |
On 3/22/19 4:28 PM, Tim Chen wrote: > On 3/19/19 7:29 PM, Subhra Mazumdar wrote: >> >> On 3/18/19 8:41 AM, Julien Desfossez wrote: >>> The case where we try to acquire the lock on 2 runqueues belonging to 2 >>> different cores requires the rq_lockp wrapper as well otherwise we >>> frequently deadlock in there. >>> >>> This fixes the crash reported in >>> 1552577311-8218-1-git-send-email-jdesfossez@digitalocean.com >>> >>> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h >>> index 76fee56..71bb71f 100644 >>> --- a/kernel/sched/sched.h >>> +++ b/kernel/sched/sched.h >>> @@ -2078,7 +2078,7 @@ static inline void double_rq_lock(struct rq *rq1, struct rq *rq2) >>> raw_spin_lock(rq_lockp(rq1)); >>> __acquire(rq2->lock); /* Fake it out ;) */ >>> } else { >>> - if (rq1 < rq2) { >>> + if (rq_lockp(rq1) < rq_lockp(rq2)) { >>> raw_spin_lock(rq_lockp(rq1)); >>> raw_spin_lock_nested(rq_lockp(rq2), SINGLE_DEPTH_NESTING); >>> } else { > > > Pawan was seeing occasional crashes and lock up that's avoided by doing the following. > We're trying to dig a little more tracing to see why pick_next_entity is returning > NULL. >
We found the root cause was a missing chunk when we port Subhra's fix of pick_next_entity
* Someone really wants this to run. If it's not unfair, run it. */ - if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) < 1) + if (left && cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) + < 1)
That fixes the problem of pick_next_entity returning NULL. sorry for the noise.
Tim
| |