http://bugzilla.kernel.org/show_bug.cgi?id=11898 ------- Comment #35 from anonymous@xxxxxxxxxxxxxxxxxxxx 2008-11-11 10:23 ------- Reply-To: michaelc@xxxxxxxxxxx James Bottomley wrote: > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > index f5d3b96..979e07a 100644 > --- a/drivers/scsi/scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -567,15 +567,18 @@ static inline int scsi_host_is_busy(struct Scsi_Host *shost) > */ > static void scsi_run_queue(struct request_queue *q) > { > - struct scsi_device *starved_head = NULL, *sdev = q->queuedata; > + struct scsi_device *tmp, *sdev = q->queuedata; > struct Scsi_Host *shost = sdev->host; > + LIST_HEAD(starved_list); > unsigned long flags; > > if (scsi_target(sdev)->single_lun) > scsi_single_lun_run(sdev); > > spin_lock_irqsave(shost->host_lock, flags); > - while (!list_empty(&shost->starved_list) && !scsi_host_is_busy(shost)) { > + list_splice_init(&shost->starved_list, &starved_list); > + > + list_for_each_entry_safe(sdev, tmp, &starved_list, starved_entry) { > int flagset; > I do not think we can use list_for_each_entry_safe. It might be he cause of the oops in the other mail. If we use list_for_each_entry_safe here, but then some other process like the kernel block workueue calls the request_fn of a device on the starved list then we can go from scsi_request_fn -> scsi_host_queue_ready which can do: /* We're OK to process the command, so we can't be starved */ if (!list_empty(&sdev->starved_entry)) list_del_init(&sdev->starved_entry); and that can end up removing the sdev from scsi_run_queue's spliced starved list. And so if the kblock workqueue did this to multiple devices while scsi_run_queue has dropped the host lock then I do not think list_for_each_entry_safe can handle that. I can sort of replicate this now. Let me do some testing on the changes and I will submit something in a minute. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
