Received: by 10.213.65.68 with SMTP id h4csp1721510imn; Mon, 19 Mar 2018 11:25:21 -0700 (PDT) X-Google-Smtp-Source: AG47ELv1eBM6onSJ3bnnWXd/oy7gf3+BVCv0ieZNZGnD8+CI671XSMIUtyspkaPI92r6+uAErev7 X-Received: by 2002:a17:902:ab84:: with SMTP id f4-v6mr13732489plr.239.1521483921402; Mon, 19 Mar 2018 11:25:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521483921; cv=none; d=google.com; s=arc-20160816; b=BlA8dB2EGjoY09O6enkONzeYNdZaS17gBYk6Tc0++Pq67gfN2Zsp2X+WHMLZH8WbVR nnGI54S4gmkreUUXzgY/MFDnl6tL/33IcrkMjr8faSBRY1huoFXmGkAqoUFQ/PTP4Wt2 +ViSVgiPzgTNk/NN/Fsmiz4fqUjvasEflXAKKNgPXmVpNIHfH/b9f6dyUHq7PJTQODFs bErrPfyuoqVFGht/+rfQiP32wL9C2dzev8Eu1eCKcFwsmqbGICf/B9y+FxfHBgjmEWyH kkI375/oVHvV0NVPBtjYOpzigs9p+ic2SIq5utytahQMMqu6LqukSgAuaGZGWChEPvGH tLtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=zcY1Vltpw7gzXqdP0G1pyGYUH13TMIFdeWtKvaR7Q0Y=; b=q+arHdxEvxg4g2Jy/BhT4uUB39yQO1TR3VB7hELr2wcFMNe/InwIcl6znNqZ7oO7u5 K9D9L64CLCVLumZUMYxB9E8nHhiQuNgzaIL8W8bulkW8+lIPAP+Z6eo8sUqXFt87Ie7L Bl2qrgpNQ+SDxIxlNMLqi15HL5EzKqqIPd7JfR2w0wDRMd4K3X/USt/rvb75iVp2vqvV dst6kqVKRwDnZN2CRUaKMl0ozwGu4MwsAuWli6CN1UcpHN2aQbnUfiTdNxN0rKimwr/E G7OKp6l7V3lIYtZ1FG6rSm62Ij674PKLs+sKtdQzOCsRC1B95K9vZfxYPrnxxBZ5fELy CYoA== 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 d14-v6si413381plj.191.2018.03.19.11.25.07; Mon, 19 Mar 2018 11:25:21 -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 S1031372AbeCSSXJ (ORCPT + 99 others); Mon, 19 Mar 2018 14:23:09 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:48728 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965658AbeCSSW5 (ORCPT ); Mon, 19 Mar 2018 14:22:57 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 8787412A2; Mon, 19 Mar 2018 18:22:56 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mauricio Faria de Oliveira , Dan Williams , Song Liu , "Martin K. Petersen" , Sasha Levin Subject: [PATCH 4.9 114/241] scsi: ses: dont get power status of SES device slot on probe Date: Mon, 19 Mar 2018 19:06:19 +0100 Message-Id: <20180319180755.922534281@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180319180751.172155436@linuxfoundation.org> References: <20180319180751.172155436@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mauricio Faria de Oliveira [ Upstream commit 75106523f39751390b5789b36ee1d213b3af1945 ] The commit 08024885a2a3 ("ses: Add power_status to SES device slot") introduced the 'power_status' attribute to enclosure components and the associated callbacks. There are 2 callbacks available to get the power status of a device: 1) ses_get_power_status() for 'struct enclosure_component_callbacks' 2) get_component_power_status() for the sysfs device attribute (these are available for kernel-space and user-space, respectively.) However, despite both methods being available to get power status on demand, that commit also introduced a call to get power status in ses_enclosure_data_process(). This dramatically increased the total probe time for SCSI devices on larger configurations, because ses_enclosure_data_process() is called several times during the SCSI devices probe and loops over the component devices (but that is another problem, another patch). That results in a tremendous continuous hammering of SCSI Receive Diagnostics commands to the enclosure-services device, which does delay the total probe time for the SCSI devices __significantly__: Originally, ~34 minutes on a system attached to ~170 disks: [ 9214.490703] mpt3sas version 13.100.00.00 loaded ... [11256.580231] scsi 17:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) With this patch, it decreased to ~2.5 minutes -- a 13.6x faster [ 1002.992533] mpt3sas version 13.100.00.00 loaded ... [ 1151.978831] scsi 11:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) Back to the commit discussion.. on the ses_get_power_status() call introduced in ses_enclosure_data_process(): impact of removing it. That may possibly be in place to initialize the power status value on device probe. However, those 2 functions available to retrieve that value _do_ automatically refresh/update it. So the potential benefit would be a direct access of the 'power_status' field which does not use the callbacks... But the only reader of 'struct enclosure_component::power_status' is the get_component_power_status() callback for sysfs attribute, and it _does_ check for and call the .get_power_status callback, (which indeed is defined and implemented by that commit), so the power status value is, again, automatically updated. So, the remaining potential for a direct/non-callback access to the power_status attribute would be out-of-tree modules -- well, for those, if they are for whatever reason interested in values that are set during device probe and not up-to-date by the time they need it.. well, that would be curious. Well, to handle that more properly, set the initial power state value to '-1' (i.e., uninitialized) instead of '1' (power 'on'), and check for it in that callback which may do an direct access to the field value _if_ a callback function is not defined. Signed-off-by: Mauricio Faria de Oliveira Fixes: 08024885a2a3 ("ses: Add power_status to SES device slot") Reviewed-by: Dan Williams Reviewed-by: Song Liu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/misc/enclosure.c | 7 ++++++- drivers/scsi/ses.c | 1 - 2 files changed, 6 insertions(+), 2 deletions(-) --- a/drivers/misc/enclosure.c +++ b/drivers/misc/enclosure.c @@ -148,7 +148,7 @@ enclosure_register(struct device *dev, c for (i = 0; i < components; i++) { edev->component[i].number = -1; edev->component[i].slot = -1; - edev->component[i].power_status = 1; + edev->component[i].power_status = -1; } mutex_lock(&container_list_lock); @@ -600,6 +600,11 @@ static ssize_t get_component_power_statu if (edev->cb->get_power_status) edev->cb->get_power_status(edev, ecomp); + + /* If still uninitialized, the callback failed or does not exist. */ + if (ecomp->power_status == -1) + return (edev->cb->get_power_status) ? -EIO : -ENOTTY; + return snprintf(buf, 40, "%s\n", ecomp->power_status ? "on" : "off"); } --- a/drivers/scsi/ses.c +++ b/drivers/scsi/ses.c @@ -548,7 +548,6 @@ static void ses_enclosure_data_process(s ecomp = &edev->component[components++]; if (!IS_ERR(ecomp)) { - ses_get_power_status(edev, ecomp); if (addl_desc_ptr) ses_process_descriptor( ecomp,