From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "mwilck@suse.com" <mwilck@suse.com>,
"hare@suse.de" <hare@suse.de>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>
Cc: "mauricfo@linux.vnet.ibm.com" <mauricfo@linux.vnet.ibm.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH v2 3/4] scsi_dh_alua: do not call BUG_ON when updating port group
Date: Mon, 15 May 2017 16:03:23 +0000 [thread overview]
Message-ID: <1494864202.2567.1.camel@sandisk.com> (raw)
In-Reply-To: <1494836189.4728.2.camel@suse.com>
On Mon, 2017-05-15 at 10:16 +0200, Martin Wilck wrote:
> On Fri, 2017-05-12 at 16:24 +0000, Bart Van Assche wrote:
> > Allowing races like the one this patch tries to address to exist
> > makes the ALUA code harder to maintain than necessary. Have you
> > considered to make alua_bus_detach() wait until ALUA work has
> > finished by using e.g. cancel_work_sync() or rcu_synchronize()?
>
> to be honest, no, I didn't consider this yet. The current kernel
> crashes with BUG() if an ALUA device is detached at an inopportune
> point in time (not just theoretically, we actually observed this). The
> goal of my patch was to fix this with minimum risk to introduce other
> problems. The addition in patch 4/4 was an attempt to address the
> concern you had expressed in your review of the v1 patch.
>
> I'm not opposed to try to find a better solution, but could we maybe
> get the fix for the BUG() (i.e. patch 3/4) applied in the first place?
> AFAICS it would not conflict with a solution like the one you
> suggested.
Hello Martin,
Sorry but I don't think it's a good idea to merge patch 3/4 in the upstream
kernel. Even with that patch applied there is nothing that prevents that
h->handler_data would be freed while alua_rtpg() is in progress and hence
that h->sdev is a completely random pointer if alua_rtpg() is executed
concurrently with alua_bus_detach(). Please do not try to paper over race
conditions but fix these properly.
Bart.
next prev parent reply other threads:[~2017-05-15 16:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-12 13:15 [PATCH v2 0/4] failover fixes for scsi_dh_alua Martin Wilck
2017-05-12 13:15 ` [PATCH v2 1/4] scsi_dh_alua: Do not modify the interval value for retries Martin Wilck
2017-05-12 16:25 ` Bart Van Assche
2017-05-12 13:15 ` [PATCH v2 2/4] scsi_dh_alua: Do not retry for unmapped device Martin Wilck
2017-05-12 16:26 ` Bart Van Assche
2017-05-12 13:15 ` [PATCH v2 3/4] scsi_dh_alua: do not call BUG_ON when updating port group Martin Wilck
2017-05-12 16:24 ` Bart Van Assche
2017-05-15 8:16 ` Martin Wilck
2017-05-15 16:03 ` Bart Van Assche [this message]
2017-05-15 18:30 ` Martin Wilck
2017-05-21 7:19 ` Christoph Hellwig
2017-05-12 13:15 ` [PATCH v2 4/4] scsi_dh_alua: take sdev reference in alua_bus_attach Martin Wilck
2017-05-12 16:21 ` 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=1494864202.2567.1.camel@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mauricfo@linux.vnet.ibm.com \
--cc=mwilck@suse.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.