Hello,
Oleg Nesterov wrote:
> void ata_port_queue_task(struct ata_port *ap, work_func_t fn, void *data,
> unsigned long delay)
> {
> - int rc;
> -
> - if (ap->pflags & ATA_PFLAG_FLUSH_PORT_TASK)
> - return;
> -
> PREPARE_DELAYED_WORK(&ap->port_task, fn);
> ap->port_task_data = data;
>
> - rc = queue_delayed_work(ata_wq, &ap->port_task, delay);
> -
> - /* rc == 0 means that another user is using port task */
> - WARN_ON(rc == 0);
> + /* may fail if ata_port_flush_task() in progress */
> + queue_delayed_work(ata_wq, &ap->port_task, delay);
> }
I don't really think ata_port_queue_task() deserves to live after this.
Feel free to kill it.
> void ata_port_flush_task(struct ata_port *ap)
> {
> - unsigned long flags;
> -
> DPRINTK("ENTER\n");
>
> - spin_lock_irqsave(ap->lock, flags);
> - ap->pflags |= ATA_PFLAG_FLUSH_PORT_TASK;
> - spin_unlock_irqrestore(ap->lock, flags);
> -
> - DPRINTK("flush #1\n");
> - cancel_work_sync(&ap->port_task.work); /* akpm: seems unneeded */
> -
> - /*
> - * At this point, if a task is running, it's guaranteed to see
> - * the FLUSH flag; thus, it will never queue pio tasks again.
> - * Cancel and flush.
> - */
> - if (!cancel_delayed_work(&ap->port_task)) {
> - if (ata_msg_ctl(ap))
> - ata_port_printk(ap, KERN_DEBUG, "%s: flush #2\n",
> - __FUNCTION__);
> - cancel_work_sync(&ap->port_task.work);
> - }
> -
> - spin_lock_irqsave(ap->lock, flags);
> - ap->pflags &= ~ATA_PFLAG_FLUSH_PORT_TASK;
> - spin_unlock_irqrestore(ap->lock, flags);
> + cancel_rearming_delayed_work(&ap->port_task);
Nor does ata_port_flush_task().
> @@ -6094,13 +6064,7 @@ void ata_port_detach(struct ata_port *ap
> spin_unlock_irqrestore(ap->lock, flags);
>
> ata_port_wait_eh(ap);
> -
> - /* Flush hotplug task. The sequence is similar to
> - * ata_port_flush_task().
> - */
> - cancel_work_sync(&ap->hotplug_task.work); /* akpm: why? */
> - cancel_delayed_work(&ap->hotplug_task);
> - cancel_work_sync(&ap->hotplug_task.work);
> + cancel_rearming_delayed_work(&ap->hotplug_task);
Yay, I've always wanted to do that. :-)
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
