Messages in this thread | | | Subject | Re: NULL pointer dereference in pick_next_task_fair | From | Kirill Tkhai <> | Date | Thu, 7 Nov 2019 18:53:02 +0300 |
| |
On 07.11.2019 18:42, Peter Zijlstra wrote: > On Thu, Nov 07, 2019 at 06:12:07PM +0300, Kirill Tkhai wrote: >> On 07.11.2019 16:26, Peter Zijlstra wrote: > >>> Urgh... throttling. > >> One more thing about current code in git. After rq->lock became able to >> be unlocked after put_prev_task() is commited, we got a new corner case. >> We usually had the same order for running task: >> >> dequeue_task() >> put_prev_task() >> >> Now the order may be reversed (this is also in case of throttling): >> >> put_prev_task() (called from pick_next_task()) >> dequeue_task() (called from another cpu) >> >> This is more theoretically, since I don't see a problem here. But there are >> too many statistics and counters in sched_class methods, that it is impossible >> to be sure all of them work as expected. > > Hmm,.. where does throttling happen on a remote CPU? I through both > cfs-bandwidth and dl throttle locally. > > Or are you talking about NO_HZ_FULL's sched_remote_tick() ?
I mean ordinary path: local throttling -> resched_curr -> schedule(). Then rq->nr_running == 0, but task is on rq. We call put_prev_task() and newidle_balance().
On another cpu someone calls set_user_nice() and it makes dequeue_task() in the middle of local cpu's newidle_balance().
Thus, we first made put_prev_task() and second dequeue_task().
| |