On 2/9/21 11:05 AM, Bodo Stroesser wrote:
> On 09.02.21 13:38, Mike Christie wrote:
>> If a cmd is on the submission workqueue then the TMR code will
>> miss it, and end up returning task not found or success for
>> lun resets. The fabric driver might then tell the initiator that
>> the running cmds have been handled when they are about to run.
>>
>> This adds a cancel when we are processing TMRs.
>>
>> Signed-off-by: Mike Christie <michael.christie@xxxxxxxxxx>
>> ---
>> drivers/target/target_core_tmr.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/target/target_core_tmr.c b/drivers/target/target_core_tmr.c
>> index 7347285471fa..9b7f159f9341 100644
>> --- a/drivers/target/target_core_tmr.c
>> +++ b/drivers/target/target_core_tmr.c
>> @@ -124,6 +124,8 @@ void core_tmr_abort_task(
>> int i;
>>
>> for (i = 0; i < dev->queue_cnt; i++) {
>> + cancel_work_sync(&dev->queues[i].sq.work);
>> +
>> spin_lock_irqsave(&dev->queues[i].lock, flags);
>> list_for_each_entry_safe(se_cmd, next, &dev->queues[i].state_list,
>> state_list) {
>> @@ -302,6 +304,8 @@ static void core_tmr_drain_state_list(
>> * in the Control Mode Page.
>> */
>> for (i = 0; i < dev->queue_cnt; i++) {
>> + cancel_work_sync(&dev->queues[i].sq.work);
>> +
>> spin_lock_irqsave(&dev->queues[i].lock, flags);
>> list_for_each_entry_safe(cmd, next, &dev->queues[i].state_list,
>> state_list) {
>>
>
> Is there a possible race?
>
> I mean, if cancel_work_sync() is called for a work that was queued but not started,
> can we end up with cmds sleeping in a queue until a further cmd is queued to the same queue?
Oh yeah, you are right cancel is wrong. It should be a flush.
