From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "ptikhomirov@virtuozzo.com" <ptikhomirov@virtuozzo.com>
Cc: "jthumshirn@suse.de" <jthumshirn@suse.de>,
"hch@lst.de" <hch@lst.de>,
"stuart.w.hayes@gmail.com" <stuart.w.hayes@gmail.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"hare@suse.com" <hare@suse.com>,
"jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>,
"khorenko@virtuozzo.com" <khorenko@virtuozzo.com>
Subject: Re: [PATCH v3 1/2] Ensure that the SCSI error handler gets woken up
Date: Tue, 5 Dec 2017 22:59:42 +0000 [thread overview]
Message-ID: <1512514780.2660.46.camel@wdc.com> (raw)
In-Reply-To: <5A27228D.1090705@virtuozzo.com>
On Wed, 2017-12-06 at 01:49 +0300, Pavel Tikhomirov wrote:
> On 12/06/2017 12:46 AM, Bart Van Assche wrote:
> > Anyway, the different scenarios I see are as follows:
> > (a) scsi_dec_host_busy() finishes before scsi_eh_inc_host_failed() starts.
> > (b) scsi_dec_host_busy() starts after scsi_eh_inc_host_failed() has
> > finished.
>
> So I think in (b) scsi_dec_host_busy starts after scsi_eh_inc_host_failed
> has _started_.
Agreed, and that's fine, since in that case the SCSI host state has alread been
modified and hence both functions will obtain the SCSI host lock. The relevant
code will be serialized through the SCSI host lock.
> > In case (a) scsi_eh_inc_host_failed() will wake up the error handler. And in
> > case (b) scsi_dec_host_busy() will wake up the error handler. So it's not
> > clear to me why you think that there is a scenario in which the EH won't be
> > woken up?
>
> So in case (b), in my understanding, scsi_dec_host_busy can skip wakeups
> as it does not see host_failed change yet.
That's not correct. If scsi_dec_host_busy() obtains the SCSI host lock before
scsi_eh_inc_host_failed() obtains it then the latter function will trigger a
SCSI EH wakeup.
Bart.
next prev parent reply other threads:[~2017-12-05 22:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-04 18:06 [PATCH v3 0/2] Ensure that the SCSI error handler gets woken up Bart Van Assche
2017-12-04 18:06 ` [PATCH v3 1/2] " Bart Van Assche
2017-12-05 10:18 ` Pavel Tikhomirov
2017-12-05 16:19 ` Bart Van Assche
[not found] ` <sr4inbsihn7krboba8euqqp1.1512508675214@email.android.com>
2017-12-05 21:46 ` Bart Van Assche
2017-12-05 22:49 ` Pavel Tikhomirov
2017-12-05 22:59 ` Bart Van Assche [this message]
2017-12-06 7:20 ` Pavel Tikhomirov
2017-12-07 5:12 ` Stuart Hayes
2017-12-04 18:06 ` [PATCH v3 2/2] Convert a source code comment into a runtime check Bart Van Assche
2017-12-07 1:55 ` [PATCH v3 0/2] Ensure that the SCSI error handler gets woken up Martin K. Petersen
2017-12-07 12:02 ` John Garry
2017-12-07 16:50 ` Bart Van Assche
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=1512514780.2660.46.camel@wdc.com \
--to=bart.vanassche@wdc.com \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=jejb@linux.vnet.ibm.com \
--cc=jthumshirn@suse.de \
--cc=khorenko@virtuozzo.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ptikhomirov@virtuozzo.com \
--cc=stable@vger.kernel.org \
--cc=stuart.w.hayes@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox