From: Lee Duncan <lduncan@suse.com>
To: Mike Christie <michael.christie@oracle.com>, linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, open-iscsi@googlegroups.com,
martin.petersen@oracle.com, mchristi@redhat.com, hare@suse.com
Subject: Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition
Date: Tue, 20 Oct 2020 09:55:30 -0700 [thread overview]
Message-ID: <480f8554-b13a-45b2-98b4-dec4762d093f@suse.com> (raw)
In-Reply-To: <47eca384-b54e-63cc-0f84-7ed6501f427e@oracle.com>
On 10/8/20 1:54 PM, Mike Christie wrote:
> On 10/8/20 12:11 PM, Mike Christie wrote:
>> On 9/25/20 1:41 PM, lduncan@suse.com wrote:
>>> From: Lee Duncan <lduncan@suse.com>
>>>
>>> iSCSI NOPs are sometimes "lost", mistakenly sent to the
>>> user-land iscsid daemon instead of handled in the kernel,
>>> as they should be, resulting in a message from the daemon like:
>>>
>>>> iscsid: Got nop in, but kernel supports nop handling.
>>>
>>> This can occur because of the forward- and back-locks
>>> in the kernel iSCSI code, and the fact that an iSCSI NOP
>>> response can be processed before processing of the NOP send
>>> is complete. This can result in "conn->ping_task" being NULL
>>> in iscsi_nop_out_rsp(), when the pointer is actually in
>>> the process of being set.
>>>
>>> To work around this, we add a new state to the "ping_task"
>>> pointer. In addition to NULL (not assigned) and a pointer
>>> (assigned), we add the state "being set", which is signaled
>>> with an INVALID pointer (using "-1").
>>>
>>> Signed-off-by: Lee Duncan <lduncan@suse.com>
>>> ---
>>> drivers/scsi/libiscsi.c | 13 ++++++++++---
>>> include/scsi/libiscsi.h | 3 +++
>>> 2 files changed, 13 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
>>> index 1e9c3171fa9f..cade108c33b6 100644
>>> --- a/drivers/scsi/libiscsi.c
>>> +++ b/drivers/scsi/libiscsi.c
>>> @@ -738,6 +738,9 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct iscsi_hdr *hdr,
>>> task->conn->session->age);
>>> }
>>>
>>> + if (unlikely(READ_ONCE(conn->ping_task) == INVALID_SCSI_TASK))
>>> + WRITE_ONCE(conn->ping_task, task);
>>> +
>>> if (!ihost->workq) {
>>> if (iscsi_prep_mgmt_task(conn, task))
>>> goto free_task;
>>
>> I think the API gets a little weird now where in some cases
>> __iscsi_conn_send_pdu checks the opcode to see what type of request
>> it is but above we the caller sets the ping_task.
>>
>> For login, tmfs and passthrough, we assume the __iscsi_conn_send_pdu
>> has sent or cleaned up everything. I think it might be nicer to just
>> have __iscsi_conn_send_pdu set the ping_task field before doing the
>> xmit/queue call. It would then work similar to the conn->login_task
>> case where that function knows about that special task too.
>>
>> So in __iscsi_conn_send_pdu add a "if (opcode == ISCSI_OP_NOOP_OUT)",
>> and check if it's a nop we need to track. If so set conn->ping_task.
>>
> Ignore this. It won't work nicely either. To figure out if the nop is
> our internal transport test ping vs a userspace ping that also needs
> a reply, we would need to do something like you did above so there is
> no point.
>
Hi Mike:
I've read this a few times, and I'm still no sure I'm parsing it correctly.
Are you saying that my original patch submission is ok, or are you
saying there's nothing we can do and we're up the proverbial creek?
--
Lee Duncan
prev parent reply other threads:[~2020-10-20 16:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 18:41 [PATCH v2 0/1] " lduncan
2020-09-25 18:41 ` [PATCH v2 1/1] " lduncan
2020-10-02 16:13 ` Lee Duncan
2020-10-08 17:11 ` Mike Christie
2020-10-08 20:54 ` Mike Christie
2020-10-20 16:55 ` Lee Duncan [this message]
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=480f8554-b13a-45b2-98b4-dec4762d093f@suse.com \
--to=lduncan@suse.com \
--cc=hare@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mchristi@redhat.com \
--cc=michael.christie@oracle.com \
--cc=open-iscsi@googlegroups.com \
/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
all inboxes | Powered by JetHome®