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: 39+ 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 ` [PATCH v3 1/7] libsas: Use static sas event pool to appease sas event lost Yijing Wang
2017-07-11 15:37 ` John Garry
2017-07-12 2:06 ` wangyijing
2017-07-12 8:17 ` John Garry
2017-07-12 8:47 ` wangyijing
2017-07-12 10:13 ` John Garry
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-11 15:54 ` John Garry
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-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-14 6:51 ` Hannes Reinecke
2017-07-14 7:46 ` wangyijing
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-12 16:50 ` John Garry
2017-07-13 2:36 ` wangyijing [this message]
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-12 13:51 ` John Garry
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-13 16:10 ` John Garry
2017-07-14 1:44 ` wangyijing
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 11:56 ` Johannes Thumshirn
2017-07-13 1:27 ` wangyijing
2017-07-13 1:37 ` wangyijing
2017-07-13 8:08 ` John Garry
2017-07-13 8:38 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).