From patchwork Sat May 20 06:39:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: wangyijing X-Patchwork-Id: 100224 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp631829qge; Fri, 19 May 2017 23:37:12 -0700 (PDT) X-Received: by 10.98.61.86 with SMTP id k83mr14509440pfa.62.1495262232622; Fri, 19 May 2017 23:37:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1495262232; cv=none; d=google.com; s=arc-20160816; b=X0HyTpUWeTzmjKsLjaFXVCC6sw3S5c84RXyouottXSBti8ZQM3Cu+FZbUJohLufy/Q hJ++ryCJTb+4Jei3iR8O40l1HTPVlRw3jdHipfoKH3l9dlgXcXITblybRLuzkwf6YJ+V NdquqwKj3rqlDngSofavvb/GvlkjA5oz7in0PP1ua/2c+QBD6mxzRjdlDOELGiVJelcp j/M8Exi1urQLaJ6xkJw/QY/SmO5MVifaAeNkphEMxi2y8UmjqEeLPpmZw2nSSDz3q+qt KJc5wnk/GfM0gawPHJ0hMXCtiJNmGCDIyh+Mv0qxO4r5DezSbp83l1/+UHUxHuk4Ci+2 HoWw== 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=LLpXWYwvURKR2IRQGqWIN4L74Ni3lxIvJT0CyEuPsPc=; b=Q1t/Nrh5XABj6wfME+83iUjIelagpPZa+Gd67s0AryPVzvbEL2oYtpj9ZYqE8VEt5B Hgz070c98WXz3qeylajA7WNilV1vM+iADbchTRPrGYDWYW58eXOajvT7gdDqptG5bhTX SyXf2wwFltJMlr+aNBiA1XFPRO38SYpVyVsefblmiXTsEshyTvYPMlzB0LyKOHgBit6j No7aFEXM5ZxswHGIEDwAO4HnwefPqhjmD/hyMaX3L5dWLIMlzce0gKVUKkmlvSGVAFTy UPaonX1ITQokkoPX3BwdUFgK7wf40I3Sd6ohUJ2/5XL8KgMVZhWm7XFyRWPKIfzUX3bV s33g== 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 u62si10165845pgd.117.2017.05.19.23.37.12; Fri, 19 May 2017 23:37:12 -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 S1752472AbdETGgZ (ORCPT + 1 other); Sat, 20 May 2017 02:36:25 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:6420 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751208AbdETGgY (ORCPT ); Sat, 20 May 2017 02:36:24 -0400 Received: from 172.30.72.53 (EHLO DGGEML401-HUB.china.huawei.com) ([172.30.72.53]) by dggrg03-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id ANZ39846; Sat, 20 May 2017 14:36:20 +0800 (CST) Received: from 138.huawei.com (10.175.124.28) by DGGEML401-HUB.china.huawei.com (10.3.17.32) with Microsoft SMTP Server id 14.3.301.0; Sat, 20 May 2017 14:36:14 +0800 From: Yijing Wang To: , CC: , , , , , , , , , , , , , , , Yijing Wang Subject: [PATCH 0/2] Enhance libsas hotplug feature Date: Sat, 20 May 2017 14:39:18 +0800 Message-ID: <1495262360-40135-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.0A090205.591FE3E5.002D, 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: a95b43e0dd21eb7ac2240ea95597d8dd Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@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. 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 | 37 +++++++++++++--- drivers/scsi/libsas/sas_internal.h | 53 ++++++++++++++++++++++ drivers/scsi/libsas/sas_phy.c | 45 ++++--------------- drivers/scsi/libsas/sas_port.c | 22 +++++----- include/scsi/libsas.h | 21 +++++---- 8 files changed, 230 insertions(+), 105 deletions(-) -- 2.5.0