From patchwork Wed Jun 14 07:36:39 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: wangyijing X-Patchwork-Id: 105459 Delivered-To: patch@linaro.org Received: by 10.140.91.77 with SMTP id y71csp165516qgd; Wed, 14 Jun 2017 00:33:52 -0700 (PDT) X-Received: by 10.84.217.25 with SMTP id o25mr3511276pli.201.1497425632294; Wed, 14 Jun 2017 00:33:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497425632; cv=none; d=google.com; s=arc-20160816; b=oEqWW5uKJfV0W0fAiBCCEbo1W72stTA2Zy7WyndoswOu0rqakHt+ORa6JugzSfhAWT AXwBNV7bChftVoaBRBpHhAZC0rPzzCW3ZfHsY+UfGHjr2+lqsPr3CEfi+rhYLnPxnU/J xAiYl7/DmkN4doxpm/G0Og1VdPHL05DEpT+/KiGHA76Z/nohPT2w0N+6Lqck1LU8E8of Ysu52jQVDMgsnCUymHV2dWqpyKTBkCQiOpzZNw7kxgNFHZ1F7NMHJmKf2WF0Lwtunkop tvPmouTj3fch0sc7CuFk/oGWyUEKcEpqGaGisOcQNEBnDPJK1dOX8dkV7ifxz325GdNe MkAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=dMI7XJkJtiBj5MNj/GtYXxwF+4oRQDLkaBOzPXVJ+f0=; b=WrWCqhF8ma5QQ/BDZI/OlaXs98lH+7FGP+NYS+dD0mG7qpxG3qEUZiuRiCdzxpN8yp qmK39QlPp+GIVwzaS8BlIn8Yc0bFXDU+ANXsmmUGkNXY1eWkPpNkWnXgLPww5EdkP6kN 65Mj1VZzKFm3anAbCBHKttIll/dAKgO9effzugPRKOuYql/9EyL5T5xAIlJgL9fZTwjI 3Sb/aO0nb7uFMrYzNXmGoHdhNogJ9RzwO8MUx4e3HooeUH+KtbQpTpA6KsqkBlifKx4m kUPyrzOKW0JKuGf8PZo/ut3DFBPXBXLcya/P4RdPziJFNroSBovAYEVIOZk1uQDQgfUY Ibdw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v1si78871plk.335.2017.06.14.00.33.51; Wed, 14 Jun 2017 00:33:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754361AbdFNHdj (ORCPT + 25 others); Wed, 14 Jun 2017 03:33:39 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:7827 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753624AbdFNHdh (ORCPT ); Wed, 14 Jun 2017 03:33:37 -0400 Received: from 172.30.72.56 (EHLO DGGEML403-HUB.china.huawei.com) ([172.30.72.56]) by dggrg02-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id API03395; Wed, 14 Jun 2017 15:33:28 +0800 (CST) Received: from 138.huawei.com (10.175.124.28) by DGGEML403-HUB.china.huawei.com (10.3.17.33) with Microsoft SMTP Server id 14.3.301.0; Wed, 14 Jun 2017 15:33:22 +0800 From: Yijing Wang To: , CC: , , , , , , , , , , , , , , , , , , , Yijing Wang Subject: [Resend][PATCH v2 0/2] Enhance libsas hotplug feature Date: Wed, 14 Jun 2017 15:36:39 +0800 Message-ID: <1497425801-19249-1-git-send-email-wangyijing@huawei.com> X-Mailer: git-send-email 2.5.0 MIME-Version: 1.0 X-Originating-IP: [10.175.124.28] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5940E6CB.000C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a3e95eabad8aa3ace00a2e307c79e75c Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Now the libsas hotplug has some issues, Dan Williams report a similar bug here before https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html The issues we have found 1. if LLDD burst reports lots of phy-up/phy-down sas events, some events may lost because a same sas events is pending now, finally libsas topo may different the hardware. 2. receive a phy down sas event, libsas call sas_deform_port to remove devices, it would first delete the sas port, then put a destruction discovery event in a new work, and queue it at the tail of workqueue, once the sas port be deleted, its children device will be deleted too, when the destruction work start, it will found the target device has been removed, and report a sysfs warnning. 3. since a hotplug process will be devided into several works, if a phy up sas event insert into phydown works, like destruction work ---> PORTE_BYTES_DMAED (sas_form_port) ---->PHYE_LOSS_OF_SIGNAL the hot remove flow would broken by PORTE_BYTES_DMAED event, it's not we expected, and issues would occur. The first patch fix the sas events lost, and the second one introudce wait-complete to fix the hotplug order issues. v1->v2: some code improvements suggested by John Garry Yijing Wang (2): libsas: Don't process sas events in static works libsas: Enhance libsas hotplug drivers/scsi/libsas/sas_discover.c | 58 +++++++++++++++++------- drivers/scsi/libsas/sas_event.c | 90 ++++++++++++++++++++++++++------------ drivers/scsi/libsas/sas_expander.c | 9 +++- drivers/scsi/libsas/sas_init.c | 29 +++++++++--- drivers/scsi/libsas/sas_internal.h | 64 +++++++++++++++++++++++++++ drivers/scsi/libsas/sas_phy.c | 45 ++++--------------- drivers/scsi/libsas/sas_port.c | 22 +++++----- include/scsi/libsas.h | 19 ++++---- 8 files changed, 232 insertions(+), 104 deletions(-) -- 2.5.0