Merge branch 'for-3.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq

Pull late workqueue fixes from Tejun Heo:
"Unfortunately, I have two really late fixes. One was for a
long-standing bug and queued for 3.8 but I found out about a
regression introduced during 3.7-rc1 two days ago, so I'm sending out
the two fixes together.

The first (long-standing) one is rescuer_thread() entering exit path
w/ TASK_INTERRUPTIBLE. It only triggers on workqueue destructions
which isn't very frequent and the exit path can usually survive being
called with TASK_INTERRUPT, so it was hidden pretty well. Apparently,
if you're reiserfs, this could lead to the exiting kthread sleeping
indefinitely holding a mutex, which is never good.

The fix is simple - restoring TASK_RUNNING before returning from the
kthread function.

The second one is introduced by the new mod_delayed_work().
mod_delayed_work() was missing special case handling for 0 delay.
Instead of queueing the work item immediately, it queued the timer
which expires on the closest next tick. Some users of the new
function converted from "[__]cancel_delayed_work() +
queue_delayed_work()" combination became unhappy with the extra delay.

Block unplugging led to noticeably higher number of context switches
and intel 6250 wireless failed to associate with WPA-Enterprise
network. The fix, again, is fairly simple. The 0 delay special case
logic from queue_delayed_work_on() should be moved to
__queue_delayed_work() which is shared by both queue_delayed_work_on()
and mod_delayed_work_on().

The first one is difficult to trigger and the failure mode for the
latter isn't completely catastrophic, so missing these two for 3.7
wouldn't make it a disastrous release, but both bugs are nasty and the
fixes are fairly safe"

* 'for-3.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
workqueue: mod_delayed_work_on() shouldn't queue timer on 0 delay
workqueue: exit rescuer_thread() as TASK_RUNNING