On 01/31, Peter Zijlstra wrote: > > On Sat, Jan 31, 2015 at 10:32:23AM -0800, Linus Torvalds wrote: > > On Fri, Jan 30, 2015 at 7:47 AM, Oleg Nesterov <o...@redhat.com> wrote: > > > > > > Perhaps sched_annotate_sleep() shouldn't depend on > > > CONFIG_DEBUG_ATOMIC_SLEEP > > > too... > > > > Ugh. That thing is horrible. The naming doesn't make it obvious at all > > that it's actually making sure that we have state set to TASK_RUNNING, > > and I could easily imagine that it would cause similar "busy-loops > > while scheduling" issues if anybody ever uses it in the wrong context. > > The alternative was putting unconditional __set_task_state(TASK_RUNNING) > things in a few code paths. I didn't want to cause the extra code in > case we didn't need them. Particularly the include/net/sock.h one, as I > know the network people are cycle counters.
And personally I agree. sched_annotate_sleep() looks self-documented, it is clear that it is used to suppress the warning. Still. Can't we avoid this subtle change in behaviour DEBUG_ATOMIC_SLEEP adds? Oleg. --- x/include/linux/kernel.h +++ x/include/linux/kernel.h @@ -176,7 +176,7 @@ extern int _cond_resched(void); */ # define might_sleep() \ do { __might_sleep(__FILE__, __LINE__, 0); might_resched(); } while (0) -# define sched_annotate_sleep() __set_current_state(TASK_RUNNING) +# define sched_annotate_sleep() (current->task_state_change = 0) #else static inline void ___might_sleep(const char *file, int line, int preempt_offset) { } --- x/kernel/sched/core.c +++ x/kernel/sched/core.c @@ -7292,7 +7292,7 @@ void __might_sleep(const char *file, int * since we will exit with TASK_RUNNING make sure we enter with it, * otherwise we will destroy state. */ - if (WARN_ONCE(current->state != TASK_RUNNING, + if (WARN_ONCE(current->state != TASK_RUNNING && current->task_state_change, "do not call blocking ops when !TASK_RUNNING; " "state=%lx set at [<%p>] %pS\n", current->state, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/