[PATCH 0/2] libata: ata_pio_task() accessing 'ap->pio_task_state' fix

[Albert Lee <albertcc@tw.ibm.com>]

Jeff,

During PIO, after calling ata_poll_qc_complete(), the next command might be
running and the value of 'ap->pio_task_state' might have been changed.
Accessing 'ap->pio_task_state' is not safe at this point.

Ex.
qc 1 completed. queuing a final task with ap->pio_task_state == PIO_ST_IDLE.
qc 2 started, queuing a new task with ap->pio_task_state set to PIO_ST.
qc 1 read ap->pio_task_state as PIO_ST; not PIO_ST_IDLE as expected.
=> 2 qc running in the workqueue with pio_task_state PIO_ST.

Changes:
  1/2: Modify ata_pio_complete() and ata_pio_block() to return
       whether qc has been completed.

  2/2: Modify ata_pio_task() to check the return value. Only queue next 
step and
        access 'ap->pio_task_state' if the command is not completed.

Patch for 2.6.13 (80ac2912f846c01d702774bb6aa7100ec71e88b9).
Tested on x86 with Promise PDC20275 and LG DVD-Multi drive.
For your review and advice, thanks.

Albert