From: Mike Christie <michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org>
To: Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Chris Leech <cleech-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
Sagi Grimberg
<sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>,
"linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Guilherme Piccoli
<gpiccoli-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
Or Gerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
Shlomo Pongratz
<shlomopongratz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 1/1] iscsi: fix regression caused by session lock patch
Date: Wed, 18 Nov 2015 12:39:23 -0600 [thread overview]
Message-ID: <564CC5DB.2040509@cs.wisc.edu> (raw)
In-Reply-To: <CAJ3xEMiu4XBO2d1oLnrgay1uLQmY871n9Kn-yp73PAkfKNnp9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/18/15, 5:30 AM, Or Gerlitz wrote:
> On Mon, Nov 16, 2015 at 7:30 PM, Michael Christie <michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org> wrote:
>>> On Nov 15, 2015, at 4:10 AM, Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Fri, Nov 13, 2015 at 6:51 PM, Mike Christie <michaelc-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org> wrote:
>>>> On 11/13/2015 09:06 AM, Or Gerlitz wrote:
>
>>> After the locking change, adding a task to any of the connection
>>> mgmtqueue, cmdqueue, or requeue lists is under the session forward lock.
>>>
>>> Removing tasks from any of these lists in iscsi_data_xmit is under
>>> the session forward lock and **before** calling down to the transport
>>> to handle the task.
>>>
>>> The iscsi_complete_task helper was added by Mike's commit
>>> 3bbaaad95fd38ded "[SCSI] libiscsi: handle cleanup task races"
>>> and is indeed typically called under the backward lock && has this section
>>>
>>> + if (!list_empty(&task->running))
>>> + list_del_init(&task->running);
>>>
>>> which per my reading of the code never comes into play, can you comment?
>
>> I had sent this to Sagi and your mellanox email the other day:
>
>> The bug occurs when a target completes a command while we are still
>> processing it. If we are doing a WRITE and the iscsi_task
>> is on the cmdqueue because we are handling a R2T.
>
> Mike,
>
> I failed to find how an iscsi_task can be added again to the cmdqueue list,
> nor how it can be added to the requeue list without the right locking, nor how
> can an iscsi_task be on either of these lists when iscsi_complete_task
> is invoked.
Are you only considering normal execution or also the cc case I
mentioned in the last mail? For normal execution we are ok.
>
> Specifically, my reading of the code says that these are the events over time:
>
> t1. queuecommand :: we put the task on the cmdqueue list
> (libiscsi.c:1741) - under fwd lock
>
> t2. iscsi_data_xmit :: we remove the task from the cmdqueue list
> (libiscsi.c:1537) - under fwd lock
>
> when the R2T flow happens, we do the following
>
> t3. iscsi_tcp_hdr_dissect --> iscsi_tcp_r2t_rsp --> iscsi_requeue_task ::
> put the task on the requeue list -- the call to iscsi_tcp_r2t_rsp is
> under the fwd lock
If the target were to send a CC at this point, we are adding the task
under the frwd lock, but the completion path would only have the back
lock. The list_empty, list_add and list_del calls then race and we could
end up in a bad state right?
>
> t4. iscsi_data_xmit :: we remove the task from the requeue list
> (libiscsi.c: 1578) - under fwd lock
We could also get the bad CC at this time and end up doing 2 list_dels
at the same time. The t4 one under the frwd lock and the cc handling
completion one under the back lock like in t3.
>
> Do you agree to t1...t4 being what's possible for a given task? or I
> missed something?
>
>>> The target shouldn't
>>> send a Check Condition at this time, but some do. If that happens, then
>>> iscsi_queuecommand could be adding a new task to the cmdqueue, while the
>>> recv path is handling the CC for the task with the outsanding R2T. The
>>> recv path iscsi_complete_task call sees that task it on the cmdqueue and
>>> deletes it from the list at the same time iscsi_queuecommand is adding a new task.
>
>
>>> This should not happen per the iscsi spec. There is some wording about
>>> waiting to finish the sequence in progress, but targets goof this up.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
next prev parent reply other threads:[~2015-11-18 18:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-12 5:05 [PATCH 1/1] iscsi: fix regression caused by session lock patch mchristi
2015-11-12 12:03 ` Sagi Grimberg
2015-11-12 20:58 ` Mike Christie
2015-11-13 15:06 ` Or Gerlitz
2015-11-13 16:51 ` Mike Christie
2015-11-15 10:10 ` Or Gerlitz
[not found] ` <CAJ3xEMhQiywXo0=kRO7f=fW--1kc6mbNs_X7wLoYtXmRWeqBkg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-11-16 17:30 ` Michael Christie
2015-11-17 16:55 ` Or Gerlitz
2015-11-18 11:30 ` Or Gerlitz
[not found] ` <CAJ3xEMiu4XBO2d1oLnrgay1uLQmY871n9Kn-yp73PAkfKNnp9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-11-18 18:39 ` Mike Christie [this message]
2016-11-07 18:15 ` Chris Leech
[not found] ` <20161107181556.cnhwst4nu63xtrqk-r8IHplWLGbA5tHQWs+pTeqPFFGjUI2lm2LY78lusg7I@public.gmane.org>
2016-11-07 18:23 ` Guilherme G. Piccoli
[not found] ` <5820C68E.6050206-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2016-11-09 5:21 ` Chris Leech
[not found] ` <20161109052142.j4psips7yvx7uohx-r8IHplWLGbA5tHQWs+pTeqPFFGjUI2lm2LY78lusg7I@public.gmane.org>
2016-11-12 1:51 ` Guilherme G. Piccoli
2017-02-06 13:19 ` Guilherme G. Piccoli
[not found] ` <631008bd-1e05-2c88-b153-695c76128eb4-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-02-06 17:27 ` Chris Leech
[not found] ` <1976057129.23970152.1486402069647.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-02-06 18:24 ` Guilherme G. Piccoli
2017-02-06 19:22 ` Sagi Grimberg
2015-11-12 21:33 ` Chris Leech
2016-01-22 16:50 ` Brian King
2016-01-22 19:11 ` Mike Christie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564CC5DB.2040509@cs.wisc.edu \
--to=michaelc-hcno3ddehluvc3sceru5cw@public.gmane.org \
--cc=cleech-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=gpiccoli-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
--cc=sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org \
--cc=shlomopongratz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).