On 2019-09-24 08:53:43 [-0500], Scott Wood wrote: > As I pointed out in the "[PATCH RT 6/8] sched: migrate_enable: Set state to > TASK_RUNNING" discussion, we can get here inside the rtmutex code (e.g. from > debug_rt_mutex_print_deadlock) where saved_state is already holding > something -- plus, the waker won't have WF_LOCK_SLEEPER and therefore > saved_state will get cleared anyway.
So let me drop the saved_state pieces and get back to it once I get to the other thread (which you replied and I didn't realised until now). Regarding the WF_LOCK_SLEEPER part. I think this works as expected. Imagine: CPU0 CPU1 spin_lock(); set_current_state(TASK_UNINTERRUPTIBLE); … spin_unlock() -> migrate_enable(); -> stop_one_cpu(); <-- A) other_func(); <-- B) schedule(); So. With only CPU0 we enter schedule() with TASK_UNINTERRUPTIBLE because the state gets preserved with the change I added (which is expected). If CPU1 sends a wake_up() at A) then the saved_state gets overwritten and we enter schedule() with TASK_RUNNING. Same happens if it is sent at B) point which is outside of any migrate/spin lock related code. Was this clear or did I miss the point? > -Scott Sebastian
