On 07/10/2017 09:06 AM, Yijing Wang wrote:
> Disco mutex was introudced to prevent domain rediscovery competing
> with ata error handling(87c8331). If we have already hold the lock
> in sas_revalidate_domain and sync executing probe, deadlock caused,
> because, sas_probe_sata() also need hold disco
On 07/10/2017 09:06 AM, Yijing Wang wrote:
> Introduce a sync flag to tag discovery event whether need to
> sync execute, per-event wait-complete ensure sync.
>
> Signed-off-by: Yijing Wang
> CC: John Garry
> CC: Johannes Thumshirn
> CC: Ewan Milne
> CC: Christoph Hellwig
> CC: Tomas Henzl
>
On 07/10/2017 09:06 AM, 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
> CC: John Garry
> CC: Johannes Thums
On 07/10/2017 09:06 AM, Yijing Wang wrote:
> Introduce wait-complete for libsas sas event processing,
> execute sas port create/destruct in sync.
>
> Signed-off-by: Yijing Wang
> CC: John Garry
> CC: Johannes Thumshirn
> CC: Ewan Milne
> CC: Christoph Hellwig
> CC: Tomas Henzl
> CC: Dan Will
On 07/10/2017 09:06 AM, Yijing Wang wrote:
> Now all libsas works are queued to scsi host workqueue,
> include sas event work post by LLDD and sas discovery
> work, and a sas hotplug flow may be divided into several
> works, e.g libsas receive a PORTE_BYTES_DMAED event,
> now we process it as follo
On 07/10/2017 09:06 AM, Yijing Wang wrote:
> No one uses the port_gone_completion in struct asd_sas_port,
> clean it out.
>
> Signed-off-by: Yijing Wang
> ---
> include/scsi/libsas.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
> index
On 07/10/2017 09:06 AM, Yijing Wang wrote:
> Now libsas hotplug work is static, every sas event type has its own
> static work, LLDD driver queue the hotplug work into shost->work_q.
> If LLDD driver burst post lots hotplug events to libsas, the hotplug
> events may pending in the workqueue like
>
在 2017/7/14 0:10, John Garry 写道:
> On 10/07/2017 08:06, Yijing Wang wrote:
>> Disco mutex was introudced to prevent domain rediscovery competing
>> with ata error handling(87c8331). If we have already hold the lock
>> in sas_revalidate_domain and sync executing probe, deadlock caused,
>> because,
On Thu, 2017-07-13 at 12:27 -0700, Nicholas A. Bellinger wrote:
> For the former, I've still never seen a host environment in the wild
> over the last 15 years that generates underflow/overflow for DATA CDBs
> with an LBA. So I'm reluctant to randomly allow this for all cases and
> fabrics, consid
Hi,
Please review the 2 patches in this series. I'm left on-the-fence
about whether there is any point re-enabling "dm-mq stacked on old
.request_fn device(s)" -- especially given the awkward details
documented in the 1/2 patch header.
I welcome any feedback on this, thanks!
BTW, I tested these
Currently if dm_mod.use_blk_mq=Y (or a DM-multipath table is loaded with
queue_mode=mq) and all underlying devices are not blk-mq, DM core will
fail with the error:
"table load rejected: all devices are not blk-mq request-stackable"
This all-blk-mq-or-nothing approach is too cut-throat because i
Conditionally use __blk_put_request() or blk_put_request() instead of
just blk_put_request() in multipath_release_clone().
Otherwise a deadlock will occur because scsi_end_request() will take the
clone request's queue_lock, around its call to blk_finish_request(), and
then the later blk_put_reques
Hi Linus,
Here are the target-pending updates for v4.13-rc1. Please go ahead and
pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next
Note there is a qla2xxx conflict with scsi.git as reported by SFR, which
should be straight-forward to resolve:
https://lk
On Tue, 2017-07-11 at 16:17 +, Bart Van Assche wrote:
> On Tue, 2017-07-11 at 00:22 -0700, Nicholas A. Bellinger wrote:
> > So rejecting this case as already done in commit abb85a9b51 is the
> > correct approach for >= v4.3.y.
>
> Hello Nic,
>
> I hope that you agree that the current target_c
Alan Stern wrote on 14/07/17 02:30:
All right. In the meantime, changing usb-storage won't hurt.
Arthur, can you test the patch below?
Alan Stern
Index: usb-4.x/drivers/usb/storage/usb.c
===
--- usb-4.x.orig/drivers/usb/stora
On 07/13/2017 01:33 AM, lixi...@cmss.chinamobile.com wrote:
> From: Xiubo Li
>
> Add some comments to make the scatter code to be more readable.
>
> Signed-off-by: Xiubo Li
> ---
Reviewed-by: Mike Christie
On Thu, 2017-07-13 at 18:23 +0800, Ming Lei wrote:
> Please discuss the congestion control in patch 4 and 5.
Hello Ming,
Since there is a significant risk that this patch series will introduce
performance and/or functional regressions, I will wait with reviewing this
patch series further until it
From: Thomas Bogendoerfer
FCOE offloading on qedf devices fails with:
[qed_sp_fcoe_func_start:150(sp-0-3b:00.02)]Cannot satisfy CQ amount. CQs
requested 8, CQs available 6. Aborting function start
[qed_fcoe_start:821()]Failed to start fcoe
[__qedf_probe:3041]:6: Cannot start FCo
Hi,
minor nit-pick on the following commit:
scsi: sg: fix SG_DXFER_FROM_DEV transfers
SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set
it to NULL for the old sg_io read/write interface, but must have a
length bigger than 0. This fixes a regression introduced by commit
28676
On Wed, 12 Jul 2017, Christoph Hellwig wrote:
> On Wed, Jul 12, 2017 at 12:10:02PM -0400, Alan Stern wrote:
> > This is pretty conclusive. The problem comes about because
> > usb_stor_control_thread() calls scsi_mq_done() while holding
> > shost->host_lock, and then scsi_eh_scmd_add() tries to ac
Hi Khazhismel,
[auto build test WARNING on mkp-scsi/for-next]
[also build test WARNING on v4.12 next-20170713]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Khazhismel-Kumykov/libiscsi-Fix-use
iscsi_session_teardown was the only user of this function. Function
currently is just short for iscsi_remove_session + iscsi_free_session.
Signed-off-by: Khazhismel Kumykov
---
drivers/scsi/scsi_transport_iscsi.c | 16
include/scsi/scsi_transport_iscsi.h | 1 -
2 files changed,
Session attributes exposed through sysfs were freed before the device
was destroyed, resulting in a potential use-after-free. Free these
attributes after removing the device.
Signed-off-by: Khazhismel Kumykov
---
drivers/scsi/libiscsi.c | 8
1 file changed, 4 insertions(+), 4 deletions(
On 10/07/2017 08:06, Yijing Wang wrote:
Disco mutex was introudced to prevent domain rediscovery competing
with ata error handling(87c8331). If we have already hold the lock
in sas_revalidate_domain and sync executing probe, deadlock caused,
because, sas_probe_sata() also need hold disco_mutex. S
Hi Khazhismel,
[auto build test ERROR on mkp-scsi/for-next]
[also build test ERROR on v4.12 next-20170713]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Khazhismel-Kumykov/libiscsi-Fix-use
Hi Khazhismel,
[auto build test ERROR on mkp-scsi/for-next]
[also build test ERROR on v4.12 next-20170713]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Khazhismel-Kumykov/libiscsi-Remove
On Wed, Jul 12, 2017 at 03:12:37PM +, Bart Van Assche wrote:
> On Wed, 2017-07-12 at 11:15 +0800, Ming Lei wrote:
> > On Tue, Jul 11, 2017 at 07:57:53PM +, Bart Van Assche wrote:
> > > On Wed, 2017-07-12 at 02:20 +0800, Ming Lei wrote:
> > > > Now SCSI won't stop queue, and not necessary to
在 2017/7/13 16:08, John Garry 写道:
> On 13/07/2017 02:37, wangyijing wrote:
>>> > So much nicer. BTW, /dev/sdb is a SATA disk, the rest are SAS.
>> Oh, I take a mistake ? The result you tested the hotplug which applied this
>> patchset is fine ?
>>
>> Thanks!
>> Yijing.
>
> Well basic hotplug is
On 13/07/2017 02:37, wangyijing wrote:
> So much nicer. BTW, /dev/sdb is a SATA disk, the rest are SAS.
Oh, I take a mistake ? The result you tested the hotplug which applied this
patchset is fine ?
Thanks!
Yijing.
Well basic hotplug is fine, as below. I did not do any robust testing.
root@
29 matches
Mail list logo
