summaryrefslogtreecommitdiff
path: root/net/phonet
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2013-08-28 21:33:37 (GMT)
committerTejun Heo <tj@kernel.org>2013-08-29 13:19:28 (GMT)
commitb22ce2785d97423846206cceec4efee0c4afd980 (patch)
treeb58beb6df891299ca0d827979c32042ce7969cc4 /net/phonet
parentc95389b4cd6a4b52af78bea706a274453e886251 (diff)
downloadlinux-fsl-qoriq-b22ce2785d97423846206cceec4efee0c4afd980.tar.xz
workqueue: cond_resched() after processing each work item
If !PREEMPT, a kworker running work items back to back can hog CPU. This becomes dangerous when a self-requeueing work item which is waiting for something to happen races against stop_machine. Such self-requeueing work item would requeue itself indefinitely hogging the kworker and CPU it's running on while stop_machine would wait for that CPU to enter stop_machine while preventing anything else from happening on all other CPUs. The two would deadlock. Jamie Liu reports that this deadlock scenario exists around scsi_requeue_run_queue() and libata port multiplier support, where one port may exclude command processing from other ports. With the right timing, scsi_requeue_run_queue() can end up requeueing itself trying to execute an IO which is asked to be retried while another device has an exclusive access, which in turn can't make forward progress due to stop_machine. Fix it by invoking cond_resched() after executing each work item. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Jamie Liu <jamieliu@google.com> References: http://thread.gmane.org/gmane.linux.kernel/1552567 Cc: stable@vger.kernel.org -- kernel/workqueue.c | 9 +++++++++ 1 file changed, 9 insertions(+)
Diffstat (limited to 'net/phonet')
0 files changed, 0 insertions, 0 deletions