Re: [PATCH 12/20] target/tmr: LUN reset cause cmd premature free.

[Bart Van Assche <bart.vanassche@sandisk.com>]

On 12/08/2015 03:48 AM, Christoph Hellwig wrote:
> On Mon, Dec 07, 2015 at 07:48:59PM -0500, Himanshu Madhani wrote:
>> From: Quinn Tran <quinn.tran@qlogic.com>
>>
>> During LUN/Target reset, the TMR code attempt to intercept
>> cmds and try to aborted them.  Current code assume cmds are
>> always intercepted at the back end device.  The cleanup code
>> would issue a "queue_status() & check_stop_free()" to terminate
>> the command.  However, when a cmd is intercepted at the front
>> end/Fabric layer, current code introduce premature free or
>> cause Fabric to double free.
>>
>> When command is intercepted at Fabric layer, it means a
>> check_stop_free(cmd_kref--) has been called.  The extra
>> check_stop_free in the Lun Reset cleanup code causes early
>> free.  When a cmd in the Fabric layer is completed, the normal
>> free code adds another another free which introduce a double free.
>>
>> To fix the issue:
>> - add a new flag/CMD_T_SENT_STATUS to track command that have
>>   made it down to fabric layer after back end good/bad completion.
>> - if cmd reach Fabric Layer at Lun Reset time, add an extra
>>   cmd_kref count to prevent premature free.
>
> This seems lke something solved by Bart's abort rewrite in a much nicer
> way.  All this special casing based on magic flags isn't maintainable
> in the long run.

Hello Himanshu and Christoph,

I am currently working on addressing the review comments on my target 
core patch series and will repost that patch series this week.

Bart.