On Fri, Jan 18, 2013 at 9:27 AM, Ewan D. Milne <[email protected]> wrote: > @@ -2206,7 +2206,7 @@ static void scsi_evt_emit(struct scsi_device *sdev, > struct scsi_event *evt) > * Dispatch queued events to their associated scsi_device kobjects > * as uevents. > */ > -void scsi_evt_thread(struct work_struct *work) > +void sdev_evt_thread(struct work_struct *work) > { > struct scsi_device *sdev; > LIST_HEAD(event_list); > @@ -2214,7 +2214,7 @@ void scsi_evt_thread(struct work_struct *work) > sdev = container_of(work, struct scsi_device, event_work); > > while (1) { > - struct scsi_event *evt; > + struct sdev_event *evt; > struct list_head *this, *tmp; > unsigned long flags; > > @@ -2226,9 +2226,9 @@ void scsi_evt_thread(struct work_struct *work) > break; > > list_for_each_safe(this, tmp, &event_list) { > - evt = list_entry(this, struct scsi_event, node); > + evt = list_entry(this, struct sdev_event, node); > list_del(&evt->node); > - scsi_evt_emit(sdev, evt); > + sdev_evt_emit(sdev, evt); > kfree(evt); > } > }
If schedule_work() gets invoked if work is already on a workqueue then it will return immediately. Does that mean that the above approach for processing the event list is racy and that new events will not get processed if schedule_work() is invoked after the while loop finished but before the above function returns ? Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
