From: wangyijing <wangyijing@huawei.com>
To: Johannes Thumshirn <jthumshirn@suse.de>,
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
Subject: Re: [PATCH v2 2/2] libsas: Enhance libsas hotplug
Date: Wed, 14 Jun 2017 17:15:43 +0800 [thread overview]
Message-ID: <5940FEBF.3020009@huawei.com> (raw)
In-Reply-To: <1fa27c30-aad7-2f19-4715-0ec02ef1a976@suse.de>
>> In this patch, we try to solve these issues in following steps:
>> 1. create a new workqueue used to run sas event work, instead of scsi host workqueue,
>> because we may block sas event work, we cannot block the normal scsi works.
>> When libsas receive a phy down event, sas_deform_port would be called, and now we
>> block sas_deform_port and wait for destruction work finish, in sas_destruct_devices,
>> we may wait ata error handler, it would take a long time, so if do all stuff in scsi
>> host workq, libsas may block other scsi works too long.
>> 2. create a new workqueue used to run sas discovery events work, instead of scsi host
>> workqueue, because in some cases, eg. in revalidate domain event, we may unregister
>> a sas device and discover new one, we must sync the execution, wait the remove process
>> finish, then start a new discovery. So we must put the probe and destruct discovery
>> events in a new workqueue to avoid deadlock.
>> 3. introudce a asd_sas_port level wait-complete and a sas_discovery level wait-complete
>> we use former wait-complete to achieve a sas event atomic process and use latter to
>> make a sas discovery sync.
>> 4. remove disco_mutex in sas_revalidate_domain, since now sas_revalidate_domain sync
>> the destruct discovery event execution, it's no need to lock disco mutex there.
>
> The way you've written the changelog suggests this patch should be split
> into 4 patches, each one taking care of one of your change items.
I will split it in next version.
Thanks!
Yijing.
>
WARNING: multiple messages have this Message-ID (diff)
From: wangyijing <wangyijing@huawei.com>
To: Johannes Thumshirn <jthumshirn@suse.de>,
<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>
Subject: Re: [PATCH v2 2/2] libsas: Enhance libsas hotplug
Date: Wed, 14 Jun 2017 17:15:43 +0800 [thread overview]
Message-ID: <5940FEBF.3020009@huawei.com> (raw)
In-Reply-To: <1fa27c30-aad7-2f19-4715-0ec02ef1a976@suse.de>
>> In this patch, we try to solve these issues in following steps:
>> 1. create a new workqueue used to run sas event work, instead of scsi host workqueue,
>> because we may block sas event work, we cannot block the normal scsi works.
>> When libsas receive a phy down event, sas_deform_port would be called, and now we
>> block sas_deform_port and wait for destruction work finish, in sas_destruct_devices,
>> we may wait ata error handler, it would take a long time, so if do all stuff in scsi
>> host workq, libsas may block other scsi works too long.
>> 2. create a new workqueue used to run sas discovery events work, instead of scsi host
>> workqueue, because in some cases, eg. in revalidate domain event, we may unregister
>> a sas device and discover new one, we must sync the execution, wait the remove process
>> finish, then start a new discovery. So we must put the probe and destruct discovery
>> events in a new workqueue to avoid deadlock.
>> 3. introudce a asd_sas_port level wait-complete and a sas_discovery level wait-complete
>> we use former wait-complete to achieve a sas event atomic process and use latter to
>> make a sas discovery sync.
>> 4. remove disco_mutex in sas_revalidate_domain, since now sas_revalidate_domain sync
>> the destruct discovery event execution, it's no need to lock disco mutex there.
>
> The way you've written the changelog suggests this patch should be split
> into 4 patches, each one taking care of one of your change items.
I will split it in next version.
Thanks!
Yijing.
>
next prev parent reply other threads:[~2017-06-14 9:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-14 7:33 [PATCH v2 0/2] Enhance libsas hotplug feature Yijing Wang
2017-06-14 7:33 ` Yijing Wang
2017-06-14 7:33 ` [PATCH v2 1/2] libsas: Don't process sas events in static works Yijing Wang
2017-06-14 7:33 ` Yijing Wang
2017-06-14 8:48 ` Johannes Thumshirn
2017-06-14 9:04 ` wangyijing
2017-06-14 9:04 ` wangyijing
2017-06-14 9:18 ` Johannes Thumshirn
2017-06-14 9:28 ` wangyijing
2017-06-14 9:28 ` wangyijing
2017-06-14 13:08 ` John Garry
2017-06-14 13:08 ` John Garry
2017-06-15 7:37 ` wangyijing
2017-06-15 7:37 ` wangyijing
2017-06-15 8:00 ` John Garry
2017-06-15 8:00 ` John Garry
2017-06-15 8:21 ` wangyijing
2017-06-15 8:21 ` wangyijing
2017-06-14 7:33 ` [PATCH v2 2/2] libsas: Enhance libsas hotplug Yijing Wang
2017-06-14 7:33 ` Yijing Wang
2017-06-14 8:57 ` Johannes Thumshirn
2017-06-14 9:15 ` wangyijing [this message]
2017-06-14 9:15 ` 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=5940FEBF.3020009@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=jthumshirn@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--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.