From: Sagi Grimberg <sagig@dev.mellanox.co.il>
To: mchristi@redhat.com, linux-scsi@vger.kernel.org
Cc: Guilherme Piccoli <gpiccoli@linux.vnet.ibm.com>,
Or Gerlitz <ogerlitz@mellanox.com>,
shlomopongratz@gmail.com
Subject: Re: [PATCH 1/1] iscsi: fix regression caused by session lock patch
Date: Thu, 12 Nov 2015 14:03:03 +0200 [thread overview]
Message-ID: <56447FF7.40600@dev.mellanox.co.il> (raw)
In-Reply-To: <1447304741-6594-1-git-send-email-mchristi@redhat.com>
> The bug is caused by this patch:
>
> 659743b02c411075b26601725947b21df0bb29c8
>
> which allowed the task lists to be manipulated under different locks
> in the xmit and completion path.
>
> To fix the oops this patch just reverts that patch. It also reverts
> these 2 patches for regressions that were also a result of that patch:
Whoa now Mike, this is a major change. Can we take a step back and think
about this for a second?
My understanding is that the kfifo circular buffer design allows a
writer (e.g. the producer) and a reader (e.g. the consumer) to avoid
extra locking when accessing the kfifo buffer.
From include/linux/kfifo.h:
/*
* Note about locking : There is no locking required until only * one
reader
* and one writer is using the fifo and no kfifo_reset() will be * called
* kfifo_reset_out() can be safely used, until it will be only called
* in the reader thread.
* For multiple writer and one reader there is only a need to lock the
writer.
* And vice versa for only one writer and multiple reader there is only
a need
* to lock the reader.
*/
The patch by Shlomo, implements the locking policy documented above:
- multiple readers: multiple threads entering queuecommand reading the
kfifo (kfifo_out) are mutually excluded by the frwd_lock.
- multiple writers: completion contexts writing to the kfifo (kfifo_in)
are mutually excluded by the back_lock.
Can you provide a more detailed analysis of why is this list corruption
triggered? What scenario was not honoring the locking policy?
This code has been running reliably in our labs for a long time now
(both iser and tcp).
Going back to a single lock restores the contention point between
queuecommand and complete_pdu.
P.S.
While we're on the subject, I'd like to see block tags replace the
kfifo for iscsi tasks. It's difficult because sw and offload drivers
map hosts/sessions differently. It can be done if we move the tasks to
the iscsi_host and have a reserved (unique) task tags for the session
login/logout/nop_in/nop_out. With this we won't need locks around our
tasks arrays.
Sagi.
next prev parent reply other threads:[~2015-11-12 12:03 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 [this message]
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
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=56447FF7.40600@dev.mellanox.co.il \
--to=sagig@dev.mellanox.co.il \
--cc=gpiccoli@linux.vnet.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=mchristi@redhat.com \
--cc=ogerlitz@mellanox.com \
--cc=shlomopongratz@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.