Messages in this thread | | | Date | Wed, 4 Mar 2020 20:25:40 -0800 | From | "Paul E. McKenney" <> | Subject | Re: Pinning down a blocked task to extract diagnostics |
| |
On Wed, Mar 04, 2020 at 10:52:26PM -0500, Steven Rostedt wrote: > On Wed, 4 Mar 2020 16:50:49 -0800 > "Paul E. McKenney" <paulmck@kernel.org> wrote: > > > Hello! > > > > Suppose that I need to extract diagnostics information from a blocked > > task, but that I absolutely cannot tolerate this task awakening in the > > midst of this extraction process. Is the following code the right way > > to make this work given a task "t"? > > > > raw_spin_lock_irq(&t->pi_lock); > > if (t->on_rq) { > > /* Task no longer blocked, so ignore it. */ > > } else { > > /* Extract consistent diagnostic information. */ > > } > > raw_spin_unlock_irq(&t->pi_lock); > > > > It looks like all the wakeup paths acquire ->pi_lock, but I figured I > > should actually ask... > > IIUC, the rtmutex code uses pi_lock to tinker with the task while it is > blocked (not woken). But the on_rq test may not be correct. It appears > that can change without holding the task's pi_lock. I'm looking at the > ttwu_do_activate() code which modifies the t->on_rq without holding the > pi_lock. Seems you may need to check the p->state as well. See the > comment in try_to_wake_up() about testing on_rq vs the state.
Thank you, Steve!
Thanx, Paul
| |