From: Jason Yan <yanaijie@huawei.com> To: John Garry <john.garry@huawei.com>, <martin.petersen@oracle.com>, <jejb@linux.vnet.ibm.com> Cc: <linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <zhaohongjiang@huawei.com>, <hare@suse.com>, <dan.j.williams@intel.com>, <jthumshirn@suse.de>, <hch@lst.de>, <huangdaode@hisilicon.com>, <chenxiang66@hisilicon.com>, <xiexiuqi@huawei.com>, <tj@kernel.org>, <miaoxie@huawei.com>, Ewan Milne <emilne@redhat.com>, Tomas Henzl <thenzl@redhat.com> Subject: Re: [PATCH 3/8] scsi: libsas: always unregister the old device if going to discover new Date: Fri, 1 Jun 2018 08:28:16 +0800 [thread overview] Message-ID: <5B109320.8040104@huawei.com> (raw) In-Reply-To: <8d3c7ee0-b76e-841f-b8e3-0346d22ae0b7@huawei.com> On 2018/5/31 23:09, John Garry wrote: > On 29/05/2018 03:23, Jason Yan wrote: >> If we went into sas_rediscover_dev() the attached_sas_addr was already >> insured not to be zero. So it's unnecessary to check if the >> attached_sas_addr is zero. >> >> And although if the sas address is not changed, we always have to >> unregister the old device when we are going to register a new one. We >> cannot just leave the device there and bring up the new. >> >> Signed-off-by: Jason Yan <yanaijie@huawei.com> >> CC: chenxiang <chenxiang66@hisilicon.com> >> CC: John Garry <john.garry@huawei.com> >> CC: Johannes Thumshirn <jthumshirn@suse.de> >> CC: Ewan Milne <emilne@redhat.com> >> CC: Christoph Hellwig <hch@lst.de> >> CC: Tomas Henzl <thenzl@redhat.com> >> CC: Dan Williams <dan.j.williams@intel.com> >> CC: Hannes Reinecke <hare@suse.com> >> --- >> drivers/scsi/libsas/sas_expander.c | 13 +++++-------- >> 1 file changed, 5 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/scsi/libsas/sas_expander.c >> b/drivers/scsi/libsas/sas_expander.c >> index 8b7114348def..629c580d906b 100644 >> --- a/drivers/scsi/libsas/sas_expander.c >> +++ b/drivers/scsi/libsas/sas_expander.c >> @@ -2054,14 +2054,11 @@ static int sas_rediscover_dev(struct >> domain_device *dev, int phy_id, bool last) >> return res; >> } >> >> - /* delete the old link */ >> - if (SAS_ADDR(phy->attached_sas_addr) && >> - SAS_ADDR(sas_addr) != SAS_ADDR(phy->attached_sas_addr)) { >> - SAS_DPRINTK("ex %016llx phy 0x%x replace %016llx\n", >> - SAS_ADDR(dev->sas_addr), phy_id, >> - SAS_ADDR(phy->attached_sas_addr)); >> - sas_unregister_devs_sas_addr(dev, phy_id, last); >> - } > > The preceeding checks in code check for no device/comm fail or SATA > flutter. > > If we're rediscovering the device and the SAS address has not changed, > then why previously still try to discover a new device? I'm guessing > sas_discover_new() had no affect in this case, since maybe since the PHY > was already discovered. When we went here, means it is not flutter, something must change, either the device type or the phy address. Then we call sas_discover_new(). And sas_discover_new() sure *have* effect in this case. Please check sas_discover_new() carefully. But that would not make sense since you say "we > are going to register a new one". Or, if we are always going to register > a new one, how did we ensure we always unregistered the old device > previously (when SAS address did not change)? > If SAS address did not change, the device type must changed, otherwise it will be a "flutter" and won't get here. So if the device type changed, do we have a reason to keep the device? I don't think so. >> + /* we always have to delete the old device when we went here */ >> + SAS_DPRINTK("ex %016llx phy 0x%x replace %016llx\n", >> + SAS_ADDR(dev->sas_addr), phy_id, >> + SAS_ADDR(phy->attached_sas_addr)); >> + sas_unregister_devs_sas_addr(dev, phy_id, last); >> >> return sas_discover_new(dev, phy_id); >> } >> > > > > . >
WARNING: multiple messages have this Message-ID (diff)
From: Jason Yan <yanaijie@huawei.com> To: John Garry <john.garry@huawei.com>, martin.petersen@oracle.com, jejb@linux.vnet.ibm.com Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, zhaohongjiang@huawei.com, hare@suse.com, dan.j.williams@intel.com, jthumshirn@suse.de, hch@lst.de, huangdaode@hisilicon.com, chenxiang66@hisilicon.com, xiexiuqi@huawei.com, tj@kernel.org, miaoxie@huawei.com, Ewan Milne <emilne@redhat.com>, Tomas Henzl <thenzl@redhat.com> Subject: Re: [PATCH 3/8] scsi: libsas: always unregister the old device if going to discover new Date: Fri, 1 Jun 2018 08:28:16 +0800 [thread overview] Message-ID: <5B109320.8040104@huawei.com> (raw) In-Reply-To: <8d3c7ee0-b76e-841f-b8e3-0346d22ae0b7@huawei.com> On 2018/5/31 23:09, John Garry wrote: > On 29/05/2018 03:23, Jason Yan wrote: >> If we went into sas_rediscover_dev() the attached_sas_addr was already >> insured not to be zero. So it's unnecessary to check if the >> attached_sas_addr is zero. >> >> And although if the sas address is not changed, we always have to >> unregister the old device when we are going to register a new one. We >> cannot just leave the device there and bring up the new. >> >> Signed-off-by: Jason Yan <yanaijie@huawei.com> >> CC: chenxiang <chenxiang66@hisilicon.com> >> CC: John Garry <john.garry@huawei.com> >> CC: Johannes Thumshirn <jthumshirn@suse.de> >> CC: Ewan Milne <emilne@redhat.com> >> CC: Christoph Hellwig <hch@lst.de> >> CC: Tomas Henzl <thenzl@redhat.com> >> CC: Dan Williams <dan.j.williams@intel.com> >> CC: Hannes Reinecke <hare@suse.com> >> --- >> drivers/scsi/libsas/sas_expander.c | 13 +++++-------- >> 1 file changed, 5 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/scsi/libsas/sas_expander.c >> b/drivers/scsi/libsas/sas_expander.c >> index 8b7114348def..629c580d906b 100644 >> --- a/drivers/scsi/libsas/sas_expander.c >> +++ b/drivers/scsi/libsas/sas_expander.c >> @@ -2054,14 +2054,11 @@ static int sas_rediscover_dev(struct >> domain_device *dev, int phy_id, bool last) >> return res; >> } >> >> - /* delete the old link */ >> - if (SAS_ADDR(phy->attached_sas_addr) && >> - SAS_ADDR(sas_addr) != SAS_ADDR(phy->attached_sas_addr)) { >> - SAS_DPRINTK("ex %016llx phy 0x%x replace %016llx\n", >> - SAS_ADDR(dev->sas_addr), phy_id, >> - SAS_ADDR(phy->attached_sas_addr)); >> - sas_unregister_devs_sas_addr(dev, phy_id, last); >> - } > > The preceeding checks in code check for no device/comm fail or SATA > flutter. > > If we're rediscovering the device and the SAS address has not changed, > then why previously still try to discover a new device? I'm guessing > sas_discover_new() had no affect in this case, since maybe since the PHY > was already discovered. When we went here, means it is not flutter, something must change, either the device type or the phy address. Then we call sas_discover_new(). And sas_discover_new() sure *have* effect in this case. Please check sas_discover_new() carefully. But that would not make sense since you say "we > are going to register a new one". Or, if we are always going to register > a new one, how did we ensure we always unregistered the old device > previously (when SAS address did not change)? > If SAS address did not change, the device type must changed, otherwise it will be a "flutter" and won't get here. So if the device type changed, do we have a reason to keep the device? I don't think so. >> + /* we always have to delete the old device when we went here */ >> + SAS_DPRINTK("ex %016llx phy 0x%x replace %016llx\n", >> + SAS_ADDR(dev->sas_addr), phy_id, >> + SAS_ADDR(phy->attached_sas_addr)); >> + sas_unregister_devs_sas_addr(dev, phy_id, last); >> >> return sas_discover_new(dev, phy_id); >> } >> > > > > . >
next prev parent reply other threads:[~2018-06-01 0:28 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-29 2:23 [PATCH 0/8] libsas: Support swapping disks and SATA phy link rate matching the pathway Jason Yan 2018-05-29 2:23 ` Jason Yan 2018-05-29 2:23 ` [PATCH 1/8] scsi: libsas: delete dead code in scsi_transport_sas.c Jason Yan 2018-05-29 2:23 ` Jason Yan 2018-05-29 7:33 ` Johannes Thumshirn 2018-05-31 14:26 ` John Garry 2018-05-31 14:26 ` John Garry 2018-05-29 2:23 ` [PATCH 2/8] scsi: libsas: check the lldd callback correctly Jason Yan 2018-05-29 2:23 ` Jason Yan 2018-05-29 7:34 ` Johannes Thumshirn 2018-05-31 14:09 ` John Garry 2018-05-31 14:09 ` John Garry 2018-06-01 0:15 ` Jason Yan 2018-06-01 0:15 ` Jason Yan 2018-05-29 2:23 ` [PATCH 3/8] scsi: libsas: always unregister the old device if going to discover new Jason Yan 2018-05-29 2:23 ` Jason Yan 2018-05-29 7:37 ` Johannes Thumshirn 2018-05-31 15:09 ` John Garry 2018-05-31 15:09 ` John Garry 2018-06-01 0:28 ` Jason Yan [this message] 2018-06-01 0:28 ` Jason Yan 2018-05-29 2:23 ` [PATCH 4/8] scsi: libsas: trigger a new revalidation to discover the device Jason Yan 2018-05-29 2:23 ` Jason Yan 2018-05-29 7:43 ` Johannes Thumshirn 2018-05-31 15:42 ` John Garry 2018-05-31 15:42 ` John Garry 2018-06-01 0:59 ` Jason Yan 2018-06-01 0:59 ` Jason Yan 2018-06-01 10:02 ` John Garry 2018-06-01 10:02 ` John Garry 2018-06-04 1:01 ` Jason Yan 2018-06-04 1:01 ` Jason Yan 2018-05-29 2:23 ` [PATCH 5/8] scsi: libsas: check if the same sata device when flutter Jason Yan 2018-05-29 2:23 ` Jason Yan 2018-05-29 2:23 ` [PATCH 6/8] scsi: libsas: reset the phy state and address if discover failed Jason Yan 2018-05-29 2:23 ` Jason Yan 2018-05-29 2:23 ` [PATCH 7/8] scsi: libsas: fix issue of swapping two sas disks Jason Yan 2018-05-29 2:23 ` Jason Yan 2018-05-29 2:23 ` [PATCH 8/8] scsi: libsas: support SATA phy link rate unmatch the pathway Jason Yan 2018-05-29 2:23 ` Jason Yan 2018-05-31 16:05 ` John Garry 2018-05-31 16:05 ` John Garry 2018-06-01 1:21 ` Jason Yan 2018-06-01 1:21 ` Jason Yan 2018-06-01 10:13 ` John Garry 2018-06-01 10:13 ` John Garry
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=5B109320.8040104@huawei.com \ --to=yanaijie@huawei.com \ --cc=chenxiang66@hisilicon.com \ --cc=dan.j.williams@intel.com \ --cc=emilne@redhat.com \ --cc=hare@suse.com \ --cc=hch@lst.de \ --cc=huangdaode@hisilicon.com \ --cc=jejb@linux.vnet.ibm.com \ --cc=john.garry@huawei.com \ --cc=jthumshirn@suse.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=miaoxie@huawei.com \ --cc=thenzl@redhat.com \ --cc=tj@kernel.org \ --cc=xiexiuqi@huawei.com \ --cc=zhaohongjiang@huawei.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: linkBe 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.