On 5/19/2016 1:54 PM, Peter Zijlstra wrote:
So the 'simple' thing is: struct rq *rq = cpu_rq(cpu); struct task_struct *task; raw_spin_lock_irq(&rq->lock); task = rq->curr; get_task_struct(task); raw_spin_unlock_irq(&rq->lock); Because by holding rq->lock, the remote CPU cannot schedule and the current task_must_ still be valid.
I will plan to use that idiom in the next patch series. Thanks!
And note; the above can result in a task which already has PF_EXITING set.
I think that should be benign though; we may generate an unnecessary warning, but somebody was doing something that could have resulted in interrupting an isolated task anyway, so warning about it is reasonable. And presumably PF_EXITING just means we don't wake any threads and leave the signal queued, but that gets flushed when the task finally exits.
The complex thing is described in the linked thread and will likely make your head hurt.
I read the linked thread and was entertained. :-) I suspect locking the runqueue may be the more robust solution anyway, and since this is presumably not a hot path, it seems easier to reason about this way. -- Chris Metcalf, Mellanox Technologies http://www.mellanox.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
