Oh well. Makes me wonder why might_sleep is testing for !TASK_RUNNABLE though. Thanks for the correction, Joe On Mon, Mar 26, 2018 at 11:35:15AM -0400, Steven Rostedt wrote: > On Fri, 23 Mar 2018 13:21:31 -0400 > joe.korty@xxxxxxxxxxxxxxxxx wrote: > > > My understanding is, in standard Linux and in rt, setting > > task state to anything other than TASK_RUNNING in of itself > > blocks preemption. > > That is clearly false. The only thing that blocks preemption with a > CONFIG_PREEMPT kernel is preempt_disable() and local_irq*() disabling. > > (Note spin_locks call preempt_disable in non RT). > > Otherwise, nothing will stop preemption. > > > A preemption is not really needed here > > as it is expected that there is a schedule() written in that > > will shortly be executed. And if a 'involuntary schedule' > > (ie, preemption) were allowed to occur between the task > > state set and the schedule(), that would change the task > > state back to TASK_RUNNING, which would cause the schedule > > to NOP. Thus we risk not having paused long enough here > > for the condition we were waiting for to become true. > > That is also incorrect. As Julia mentioned, a preemption keeps the > state of the task. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
