From: wangyijing <wangyijing@huawei.com>
To: John Garry <john.garry@huawei.com>,
jejb@linux.vnet.ibm.com, martin.petersen@oracle.com
Cc: chenqilin2@huawei.com, hare@suse.com, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org, chenxiang66@hisilicon.com,
huangdaode@hisilicon.com, wangkefeng.wang@huawei.com,
zhaohongjiang@huawei.com, dingtianhong@huawei.com,
guohanjun@huawei.com, yanaijie@huawei.com, hch@lst.de,
dan.j.williams@intel.com, emilne@redhat.com, thenzl@redhat.com,
wefu@redhat.com, charles.chenxin@huawei.com,
chenweilong@huawei.com, Johannes Thumshirn <jthumshirn@suse.de>,
Linuxarm <linuxarm@huawei.com>
Subject: Re: [PATCH v3 5/7] libsas: add a new workqueue to run probe/destruct discovery event
Date: Thu, 13 Jul 2017 10:36:01 +0800 [thread overview]
Message-ID: <5966DC91.1090200@huawei.com> (raw)
In-Reply-To: <b1c7f058-c450-beb3-a909-8129e7042f87@huawei.com>
在 2017/7/13 0:50, John Garry 写道:
> On 10/07/2017 08:06, Yijing Wang wrote:
>> Sometimes, we want sync libsas probe or destruct in sas discovery work,
>> like when libsas revalidate domain. We need to split probe and destruct
>> work from the scsi host workqueue.
>>
>> Signed-off-by: Yijing Wang <wangyijing@huawei.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>
>> ---
>> drivers/scsi/libsas/sas_discover.c | 13 ++++++++++++-
>> drivers/scsi/libsas/sas_init.c | 8 ++++++++
>> include/scsi/libsas.h | 1 +
>> 3 files changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/scsi/libsas/sas_discover.c b/drivers/scsi/libsas/sas_discover.c
>> index 5d4a3a8..a25d648 100644
>> --- a/drivers/scsi/libsas/sas_discover.c
>> +++ b/drivers/scsi/libsas/sas_discover.c
>> @@ -559,7 +559,18 @@ static void sas_chain_work(struct sas_ha_struct *ha, struct sas_work *sw)
>> * not racing against draining
>> */
>> sas_port_get(port);
>> - ret = scsi_queue_work(ha->core.shost, &sw->work);
>> + /*
>> + * discovery event probe and destruct would be called in other
>> + * discovery event like discover domain and revalidate domain
>> + * events, in some cases, we need to sync execute probe and destruct
>> + * events, so run probe and destruct discover events except in a new
>> + * workqueue.
>
> Can we just use ha->disc_q for all discovery events for simplicity? Would this solve the disco mutex you try to solve in patch 7/7?
No, since we could queue sas discovery probe/destruct event in sas discovery work(like sas_revalidate_domain)
sas_revalidate_domain
sas_ex_revalidate_domain
sas_rediscover
sas_rediscover_dev
sas_unregister_devs_sas_addr
sas_unregister_dev
sas_discover_event(dev->port, DISCE_DESTRUCT)
sas_discover_new
sas_ex_discover_devices
sas_ex_discover_dev
sas_ex_discover_end_dev
sas_discover_end_dev
sas_discover_event(dev->port, DISCE_PROBE)
So we could not sync probe or destruct sas discovery event in sas_revalidate_domain if they are queued in a same workqueue,
or it would block for ever.
>
>> + */
>> + if (ev->type == DISCE_PROBE || ev->type == DISCE_DESTRUCT)
>> + ret = queue_work(ha->disc_q, &sw->work);
>> + else
>> + ret = scsi_queue_work(ha->core.shost, &sw->work);
>> +
>> if (ret != 1)
>
> Uhh, we are mixing bool and int here... but we're forced to by scsi_queue_work()
Eagle eye :), I could check the return value separately.
Thanks!
Yijing.
>
>> sas_port_put(port);
>> }
>> diff --git a/drivers/scsi/libsas/sas_init.c b/drivers/scsi/libsas/sas_init.c
>> index 2f3b736..df1d78b 100644
>> --- a/drivers/scsi/libsas/sas_init.c
>> +++ b/drivers/scsi/libsas/sas_init.c
>> @@ -152,6 +152,13 @@ int sas_register_ha(struct sas_ha_struct *sas_ha)
>> if (!sas_ha->event_q)
>> goto Undo_ports;
>>
>> + snprintf(name, 64, "%s_disc_q", dev_name(sas_ha->dev));
>> + sas_ha->disc_q = create_singlethread_workqueue(name);
>> + if(!sas_ha->disc_q) {
>> + destroy_workqueue(sas_ha->event_q);
>> + goto Undo_ports;
>> + }
>> +
>> INIT_LIST_HEAD(&sas_ha->eh_done_q);
>> INIT_LIST_HEAD(&sas_ha->eh_ata_q);
>>
>> @@ -187,6 +194,7 @@ int sas_unregister_ha(struct sas_ha_struct *sas_ha)
>> __sas_drain_work(sas_ha);
>> mutex_unlock(&sas_ha->drain_mutex);
>> destroy_workqueue(sas_ha->event_q);
>> + destroy_workqueue(sas_ha->disc_q);
>>
>> return 0;
>> }
>> diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
>> index c2ef05e..4bcb9fe 100644
>> --- a/include/scsi/libsas.h
>> +++ b/include/scsi/libsas.h
>> @@ -406,6 +406,7 @@ struct sas_ha_struct {
>> struct device *dev; /* should be set */
>> struct module *lldd_module; /* should be set */
>> struct workqueue_struct *event_q;
>> + struct workqueue_struct *disc_q;
>>
>> u8 *sas_addr; /* must be set */
>> u8 hashed_sas_addr[HASHED_SAS_ADDR_SIZE];
>>
>
>
>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: wangyijing <wangyijing@huawei.com>
To: John Garry <john.garry@huawei.com>, <jejb@linux.vnet.ibm.com>,
<martin.petersen@oracle.com>
Cc: <chenqilin2@huawei.com>, <hare@suse.com>,
<linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<chenxiang66@hisilicon.com>, <huangdaode@hisilicon.com>,
<wangkefeng.wang@huawei.com>, <zhaohongjiang@huawei.com>,
<dingtianhong@huawei.com>, <guohanjun@huawei.com>,
<yanaijie@huawei.com>, <hch@lst.de>, <dan.j.williams@intel.com>,
<emilne@redhat.com>, <thenzl@redhat.com>, <wefu@redhat.com>,
<charles.chenxin@huawei.com>, <chenweilong@huawei.com>,
Johannes Thumshirn <jthumshirn@suse.de>,
Linuxarm <linuxarm@huawei.com>
Subject: Re: [PATCH v3 5/7] libsas: add a new workqueue to run probe/destruct discovery event
Date: Thu, 13 Jul 2017 10:36:01 +0800 [thread overview]
Message-ID: <5966DC91.1090200@huawei.com> (raw)
In-Reply-To: <b1c7f058-c450-beb3-a909-8129e7042f87@huawei.com>
在 2017/7/13 0:50, John Garry 写道:
> On 10/07/2017 08:06, Yijing Wang wrote:
>> Sometimes, we want sync libsas probe or destruct in sas discovery work,
>> like when libsas revalidate domain. We need to split probe and destruct
>> work from the scsi host workqueue.
>>
>> Signed-off-by: Yijing Wang <wangyijing@huawei.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>
>> ---
>> drivers/scsi/libsas/sas_discover.c | 13 ++++++++++++-
>> drivers/scsi/libsas/sas_init.c | 8 ++++++++
>> include/scsi/libsas.h | 1 +
>> 3 files changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/scsi/libsas/sas_discover.c b/drivers/scsi/libsas/sas_discover.c
>> index 5d4a3a8..a25d648 100644
>> --- a/drivers/scsi/libsas/sas_discover.c
>> +++ b/drivers/scsi/libsas/sas_discover.c
>> @@ -559,7 +559,18 @@ static void sas_chain_work(struct sas_ha_struct *ha, struct sas_work *sw)
>> * not racing against draining
>> */
>> sas_port_get(port);
>> - ret = scsi_queue_work(ha->core.shost, &sw->work);
>> + /*
>> + * discovery event probe and destruct would be called in other
>> + * discovery event like discover domain and revalidate domain
>> + * events, in some cases, we need to sync execute probe and destruct
>> + * events, so run probe and destruct discover events except in a new
>> + * workqueue.
>
> Can we just use ha->disc_q for all discovery events for simplicity? Would this solve the disco mutex you try to solve in patch 7/7?
No, since we could queue sas discovery probe/destruct event in sas discovery work(like sas_revalidate_domain)
sas_revalidate_domain
sas_ex_revalidate_domain
sas_rediscover
sas_rediscover_dev
sas_unregister_devs_sas_addr
sas_unregister_dev
sas_discover_event(dev->port, DISCE_DESTRUCT)
sas_discover_new
sas_ex_discover_devices
sas_ex_discover_dev
sas_ex_discover_end_dev
sas_discover_end_dev
sas_discover_event(dev->port, DISCE_PROBE)
So we could not sync probe or destruct sas discovery event in sas_revalidate_domain if they are queued in a same workqueue,
or it would block for ever.
>
>> + */
>> + if (ev->type == DISCE_PROBE || ev->type == DISCE_DESTRUCT)
>> + ret = queue_work(ha->disc_q, &sw->work);
>> + else
>> + ret = scsi_queue_work(ha->core.shost, &sw->work);
>> +
>> if (ret != 1)
>
> Uhh, we are mixing bool and int here... but we're forced to by scsi_queue_work()
Eagle eye :), I could check the return value separately.
Thanks!
Yijing.
>
>> sas_port_put(port);
>> }
>> diff --git a/drivers/scsi/libsas/sas_init.c b/drivers/scsi/libsas/sas_init.c
>> index 2f3b736..df1d78b 100644
>> --- a/drivers/scsi/libsas/sas_init.c
>> +++ b/drivers/scsi/libsas/sas_init.c
>> @@ -152,6 +152,13 @@ int sas_register_ha(struct sas_ha_struct *sas_ha)
>> if (!sas_ha->event_q)
>> goto Undo_ports;
>>
>> + snprintf(name, 64, "%s_disc_q", dev_name(sas_ha->dev));
>> + sas_ha->disc_q = create_singlethread_workqueue(name);
>> + if(!sas_ha->disc_q) {
>> + destroy_workqueue(sas_ha->event_q);
>> + goto Undo_ports;
>> + }
>> +
>> INIT_LIST_HEAD(&sas_ha->eh_done_q);
>> INIT_LIST_HEAD(&sas_ha->eh_ata_q);
>>
>> @@ -187,6 +194,7 @@ int sas_unregister_ha(struct sas_ha_struct *sas_ha)
>> __sas_drain_work(sas_ha);
>> mutex_unlock(&sas_ha->drain_mutex);
>> destroy_workqueue(sas_ha->event_q);
>> + destroy_workqueue(sas_ha->disc_q);
>>
>> return 0;
>> }
>> diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
>> index c2ef05e..4bcb9fe 100644
>> --- a/include/scsi/libsas.h
>> +++ b/include/scsi/libsas.h
>> @@ -406,6 +406,7 @@ struct sas_ha_struct {
>> struct device *dev; /* should be set */
>> struct module *lldd_module; /* should be set */
>> struct workqueue_struct *event_q;
>> + struct workqueue_struct *disc_q;
>>
>> u8 *sas_addr; /* must be set */
>> u8 hashed_sas_addr[HASHED_SAS_ADDR_SIZE];
>>
>
>
>
> .
>
next prev parent reply other threads:[~2017-07-13 2:36 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 7:06 [PATCH v3 0/7] Enhance libsas hotplug feature Yijing Wang
2017-07-10 7:06 ` Yijing Wang
2017-07-10 7:06 ` [PATCH v3 1/7] libsas: Use static sas event pool to appease sas event lost Yijing Wang
2017-07-10 7:06 ` Yijing Wang
2017-07-11 15:37 ` John Garry
2017-07-11 15:37 ` John Garry
2017-07-12 2:06 ` wangyijing
2017-07-12 2:06 ` wangyijing
2017-07-12 8:17 ` John Garry
2017-07-12 8:17 ` John Garry
2017-07-12 8:47 ` wangyijing
2017-07-12 8:47 ` wangyijing
2017-07-12 10:13 ` John Garry
2017-07-12 10:13 ` John Garry
2017-07-13 2:13 ` wangyijing
2017-07-13 2:13 ` wangyijing
2017-07-14 6:40 ` Hannes Reinecke
2017-07-10 7:06 ` [PATCH v3 2/7] libsas: remove unused port_gone_completion Yijing Wang
2017-07-10 7:06 ` Yijing Wang
2017-07-11 15:54 ` John Garry
2017-07-11 15:54 ` John Garry
2017-07-12 2:18 ` wangyijing
2017-07-12 2:18 ` wangyijing
2017-07-14 6:40 ` Hannes Reinecke
2017-07-10 7:06 ` [PATCH v3 3/7] libsas: Use new workqueue to run sas event Yijing Wang
2017-07-10 7:06 ` Yijing Wang
2017-07-14 6:42 ` Hannes Reinecke
2017-07-10 7:06 ` [PATCH v3 4/7] libsas: add sas event wait-complete support Yijing Wang
2017-07-10 7:06 ` Yijing Wang
2017-07-14 6:51 ` Hannes Reinecke
2017-07-14 7:46 ` wangyijing
2017-07-14 7:46 ` wangyijing
2017-07-14 8:42 ` John Garry
2017-07-14 8:42 ` John Garry
2017-07-10 7:06 ` [PATCH v3 5/7] libsas: add a new workqueue to run probe/destruct discovery event Yijing Wang
2017-07-10 7:06 ` Yijing Wang
2017-07-12 16:50 ` John Garry
2017-07-12 16:50 ` John Garry
2017-07-13 2:36 ` wangyijing [this message]
2017-07-13 2:36 ` wangyijing
2017-07-14 6:52 ` Hannes Reinecke
2017-07-10 7:06 ` [PATCH v3 6/7] libsas: add wait-complete support to sync " Yijing Wang
2017-07-10 7:06 ` Yijing Wang
2017-07-12 13:51 ` John Garry
2017-07-12 13:51 ` John Garry
2017-07-13 2:19 ` wangyijing
2017-07-13 2:19 ` wangyijing
2017-07-14 6:53 ` Hannes Reinecke
2017-07-10 7:06 ` [PATCH v3 7/7] libsas: release disco mutex during waiting in sas_ex_discover_end_dev Yijing Wang
2017-07-10 7:06 ` Yijing Wang
2017-07-13 16:10 ` John Garry
2017-07-13 16:10 ` John Garry
2017-07-14 1:44 ` wangyijing
2017-07-14 1:44 ` wangyijing
2017-07-14 8:26 ` John Garry
2017-07-14 8:26 ` John Garry
2017-07-14 6:55 ` Hannes Reinecke
2017-07-12 9:59 ` [PATCH v3 0/7] Enhance libsas hotplug feature John Garry
2017-07-12 9:59 ` John Garry
2017-07-12 11:56 ` Johannes Thumshirn
2017-07-13 1:27 ` wangyijing
2017-07-13 1:27 ` wangyijing
2017-07-13 1:37 ` wangyijing
2017-07-13 1:37 ` wangyijing
2017-07-13 8:08 ` John Garry
2017-07-13 8:08 ` John Garry
2017-07-13 8:38 ` wangyijing
2017-07-13 8:38 ` wangyijing
2017-07-14 8:19 ` wangyijing
2017-07-14 8:19 ` wangyijing
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=5966DC91.1090200@huawei.com \
--to=wangyijing@huawei.com \
--cc=charles.chenxin@huawei.com \
--cc=chenqilin2@huawei.com \
--cc=chenweilong@huawei.com \
--cc=chenxiang66@hisilicon.com \
--cc=dan.j.williams@intel.com \
--cc=dingtianhong@huawei.com \
--cc=emilne@redhat.com \
--cc=guohanjun@huawei.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=linuxarm@huawei.com \
--cc=martin.petersen@oracle.com \
--cc=thenzl@redhat.com \
--cc=wangkefeng.wang@huawei.com \
--cc=wefu@redhat.com \
--cc=yanaijie@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: 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.