From patchwork Mon Jul 10 07:06:02 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: wangyijing X-Patchwork-Id: 107273 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp3037689qge; Mon, 10 Jul 2017 00:02:21 -0700 (PDT) X-Received: by 10.84.215.140 with SMTP id l12mr16744726pli.133.1499670141856; Mon, 10 Jul 2017 00:02:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499670141; cv=none; d=google.com; s=arc-20160816; b=XCPtBDKJh2bPPPG21uKpGdFmsmGuw9dRhMEsGPhTiC5w2sraYOriFTfTjAIasIp8lD mR+pb55nT7bmCDASSVl5qFBJ4XAr5h1HIFTr/cSX2yZdKZvk+hDjH3qphR7d3MFQl9IU Dm8sMlUWhqjQ1fcEK/GHv9QKdakWZOnE4vioRU4uY3Xuw4VnRJofWjLqFh72qTN9rODU xfNRDzfrhfEV4NFOXfYy6MjW2sLwUSDLdGnc+OiYYCOz7oPHhWEqqYqq8sOSN4zx/dUP Tlm6QcRihp0NdyqD60+N+MzeKnqafSKTVYeMTQP7EPHaosMsrU4ivebb7evMa3tSPKb7 gNsA== 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=32iG1aiN1lc4KPPfLMwAD5rpdkG1yiCuHx16rxYG1LA=; b=fLVmpHzkP/AfH+dL2Mdjb8KVfBdw/qIn+6zYPmorqPJZ89+1gNZRrPvMxTSgQ4yH4B HcXF29gd9w207gQHYShOonR2mJyp0ZygJet1USaSnsnTY+F0QCn9KUOHizpNim/BU4ip 4/3EtiMwfv5+J6nKRcQQB8UdEFJ52v7w0vza5Ylzxe2naaUU5PRMDQJemT3nNsJHNEsy 2ek+mzHPCxtWPXRHuj3bIJIOVdj8bYymIZTtYtv0KDIdkOUhd6hRvpoDvhaxtfwf9n90 FftlCOcCqr83Qp7KEYqjnza8jiAI5xThI3RVXkTYvY7e86M/doC+PB+Gb5zVenZGXBcR bM8w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-scsi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-scsi-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 u1si7286725pfa.258.2017.07.10.00.02.21; Mon, 10 Jul 2017 00:02:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-scsi-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-scsi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-scsi-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752335AbdGJHCV (ORCPT + 1 other); Mon, 10 Jul 2017 03:02:21 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:9294 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751835AbdGJHCU (ORCPT ); Mon, 10 Jul 2017 03:02:20 -0400 Received: from 172.30.72.54 (EHLO dggeml406-hub.china.huawei.com) ([172.30.72.54]) by dggrg01-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id ARU37598; Mon, 10 Jul 2017 15:02:11 +0800 (CST) Received: from 138.huawei.com (10.175.124.28) by dggeml406-hub.china.huawei.com (10.3.17.50) with Microsoft SMTP Server id 14.3.301.0; Mon, 10 Jul 2017 15:02:00 +0800 From: Yijing Wang To: , CC: , , , , , , , , , , , , , , , , , , , Yijing Wang Subject: [PATCH v3 0/7] Enhance libsas hotplug feature Date: Mon, 10 Jul 2017 15:06:02 +0800 Message-ID: <1499670369-44143-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.0A020204.59632673.0136, 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: 2e42517882e7c0bfdb9f6e0943de0b08 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org This patchset is based Johannes's patch "scsi: sas: scsi_queue_work can fail, so make callers aware" 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. v2->v3: some code improvements suggested by Johannes and John, split v2 patch 2 into several small pathes. v1->v2: some code improvements suggested by John Garry Yijing Wang (7): libsas: Use static sas event pool to appease sas event lost libsas: remove unused port_gone_completion libsas: Use new workqueue to run sas event libsas: add sas event wait-complete support libsas: add a new workqueue to run probe/destruct discovery event libsas: add wait-complete support to sync discovery event libsas: release disco mutex during waiting in sas_ex_discover_end_dev drivers/scsi/libsas/sas_discover.c | 58 +++++++--- drivers/scsi/libsas/sas_event.c | 212 ++++++++++++++++++++++++++++++++----- drivers/scsi/libsas/sas_expander.c | 22 +++- drivers/scsi/libsas/sas_init.c | 21 ++-- drivers/scsi/libsas/sas_internal.h | 64 +++++++++++ drivers/scsi/libsas/sas_phy.c | 48 +++------ drivers/scsi/libsas/sas_port.c | 22 ++-- include/scsi/libsas.h | 27 +++-- 8 files changed, 373 insertions(+), 101 deletions(-) -- 2.5.0