On Fri, Jan 18, 2013 at 9:27 AM, Ewan D. Milne <emilne@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
