I'm back in town now and ready to try this again. Should I still try
this patch? I noticed you had submitted a patch a few days ago, so
can I just pull all the latest updates from your git repo?
Thanks
On Sun, Mar 6, 2016 at 2:13 PM, Dan Lane <dracodan@xxxxxxxxx> wrote:
> On Sat, Mar 5, 2016 at 10:45 PM, Nicholas A. Bellinger
> <nab@xxxxxxxxxxxxxxx> wrote:
>> On Sat, 2016-03-05 at 22:15 -0500, Dan Lane wrote:
>>
>> <SNIP>
>>
>>> Unfortunately it looks like target caused a kernel oops before I had a
>>> chance to test those. Please see the attached crash log.
>>>
>>
>> While doing stable backports this afternoon for the series you've been
>> testing, I noticed the following scenario can occur during ABORT_TASK
>> processing, if / when __target_check_io_state() detects an already
>> completed command.
>>
>> Since you are triggering constant ABORT_TASKs it makes sense you'd
>> eventually hit this, and AFAICT your new stack-backtrace looks like a
>> use-after-free along these lines.
>>
>> Please apply the following one-line change to your tree:
>>
>> diff --git a/drivers/target/target_core_tmr.c b/drivers/target/target_core_tmr.c
>> index 82a663b..4f229e7 100644
>> --- a/drivers/target/target_core_tmr.c
>> +++ b/drivers/target/target_core_tmr.c
>> @@ -177,7 +177,6 @@ void core_tmr_abort_task(
>>
>> if (!__target_check_io_state(se_cmd, se_sess, 0)) {
>> spin_unlock_irqrestore(&se_sess->sess_cmd_lock, flags);
>> - target_put_sess_cmd(se_cmd);
>> goto out;
>> }
>> list_del_init(&se_cmd->se_cmd_list);
>>
>>> The one thing I can answer is that I used "option #1 host side ATS
>>> heartbeat disabled".
>>>
>>
>> Good, thanks for confirming.
>>
>
> Unfortunately I won't have time to do this before next Friday.
>
> Dan
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
