From: Martin Wilck <mwilck@suse.com>
To: Bart Van Assche <Bart.VanAssche@sandisk.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 20:30:19 +0200 [thread overview]
Message-ID: <1494873019.4728.11.camel@suse.com> (raw)
In-Reply-To: <1494864202.2567.1.camel@sandisk.com>
On Mon, 2017-05-15 at 16:03 +0000, Bart Van Assche wrote:
> 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.
Hello Bart,
please be assured that I'm not trying to paper over anything. Your
concern about sdev->handler_data is justified. While I think that it's
a separate issue from what my patches were supposed to address, let me
see if I can come up with something more comprehensive.
It will take time, though, until I fully comprehend the locking concept
of scsi_dh_alua.c.
Regards,
Martin
--
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
next prev parent reply other threads:[~2017-05-15 18:30 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
2017-05-15 18:30 ` Martin Wilck [this message]
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=1494873019.4728.11.camel@suse.com \
--to=mwilck@suse.com \
--cc=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 \
/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.