From patchwork Fri Sep 27 09:20:45 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jinpu Wang X-Patchwork-Id: 2953481 Return-Path: X-Original-To: patchwork-linux-rdma@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 8BC6F9F288 for ; Fri, 27 Sep 2013 09:20:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id AF98B2034F for ; Fri, 27 Sep 2013 09:20:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 53C8020348 for ; Fri, 27 Sep 2013 09:20:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752733Ab3I0JUf (ORCPT ); Fri, 27 Sep 2013 05:20:35 -0400 Received: from mail-bk0-f42.google.com ([209.85.214.42]:60709 "EHLO mail-bk0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752206Ab3I0JUe (ORCPT ); Fri, 27 Sep 2013 05:20:34 -0400 Received: by mail-bk0-f42.google.com with SMTP id my10so882303bkb.1 for ; Fri, 27 Sep 2013 02:20:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type; bh=TIEofy3ATSNvfuk6KGtZ/wHskC1ED1ZPH2aDyttslw8=; b=Vru89AA7shkuEZybeFcO04vip+isJN/74LIUFXQ/s4+zDiZUZ7RvvdJM+C9uy108CQ k3vw1FPqJRfKGCLNbWZTRgzmOF3Iqc9JrW8Rb8wENg2tKu7+Yfk0zxCG6cKp4CfnL1QK jOk+OkX6BdN6HSaqQefk/0aNNxdhB31x5pS8M1LB6CAxp+62vL+z6ZTcLMaYL9B0kTsF yNNWvx6glOnt71oMUksrSHMrdUPkoj7+iJGxFuCeDNI5fTRTr7WsaT7cgjApDwAlLn0Q 4pj/HkLBWpA4EetaG2Ysj8lEBpmStMCGXSnDEVU05wAu+DrWV739uOqWgZfLNgWk2pDQ uUTA== X-Gm-Message-State: ALoCoQn+QxPh5syqlnx4TWtmg/dU/3NaLS7gourGHu6Bq8XS6uRzEltlQ52cLbwfIKQGKHvqOmTZ X-Received: by 10.205.64.9 with SMTP id xg9mr883283bkb.30.1380273632538; Fri, 27 Sep 2013 02:20:32 -0700 (PDT) Received: from [192.168.88.32] ([62.217.45.26]) by mx.google.com with ESMTPSA id qe6sm3393840bkb.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 02:20:32 -0700 (PDT) Message-ID: <52454DED.6020309@profitbricks.com> Date: Fri, 27 Sep 2013 11:20:45 +0200 From: Jack Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Bart Van Assche , Roland Dreier CC: Dongsu Park , David Dillow , linux-rdma Subject: [PATCH]SRP: fix task management handle in srp Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Spam-Status: No, score=-9.3 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi all, Currently handle of srp_rsp for task management is broken. in 6.9 T10/1415-D revision 16a SRP_RSP responses that contain either RESPONSE DATA or SENSE DATA shall be sent as the minimum length message containing those fields. LENGTH field specify the number of bytes in the RESPONSE DATA field. RSPVALID set to one also indicates that the contents of the STATUS field shall be ignored by the SRP initiator port. If response data is provided, RSPVALID shall be set to one and the RESPONSE DATA LIST LENGTH field shall specify the number of bytes in the RESPONSE DATA field (see table 23). The RESPONSE DATA LIST LENGTH field shall contain the value four. Other lengths are reserved for future standardization. If no response data is provided, RSPVALID shall be set to zero. The SRP initiator port shall ignore the RESPONSE DATA LIST LENGTH field and shall assume a length of zero. Response data shall be provided in any SRP_RSP response that is sent in response to an SRP_TSK_MGMT request (see 6.7). The information in the RSP_CODE field (see table 24) shall indicate the completion status of the task management function. Response data shall not be provided in any SRP_RSP response that returns a non-zero status code in the STATUS field. The STATUS field contains the status of a task that completes. Patch made against v3.12-rc1 From 5f5af6de8dd72e37448841b7d7735d3eea4d3d83 Mon Sep 17 00:00:00 2001 From: Jack Wang Date: Fri, 27 Sep 2013 11:10:05 +0200 Subject: [PATCH] IB/srp: fix task management handle in srp Currently the srp driver process task manamgement command in wrong way it just ignore the return srp_rsp for successful case eg rsp->status is success, fix this. Signed-off-by: Jack Wang Reviewed-by: Dongsu Park --- drivers/infiniband/ulp/srp/ib_srp.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) req = &target->req_ring[rsp->tag]; @@ -1739,7 +1741,7 @@ static int srp_send_tsk_mgmt(struct srp_target_port *target, msecs_to_jiffies(SRP_ABORT_TIMEOUT_MS))) return -1; - return 0; + return target->tsk_mgmt_status; } static int srp_abort(struct scsi_cmnd *scmnd) @@ -1776,8 +1778,6 @@ static int srp_reset_device(struct scsi_cmnd *scmnd) if (srp_send_tsk_mgmt(target, SRP_TAG_NO_REQ, scmnd->device->lun, SRP_TSK_LUN_RESET)) return FAILED; - if (target->tsk_mgmt_status) - return FAILED; for (i = 0; i < SRP_CMD_SQ_SIZE; ++i) { struct srp_request *req = &target->req_ring[i]; From 5f5af6de8dd72e37448841b7d7735d3eea4d3d83 Mon Sep 17 00:00:00 2001 From: Jack Wang Date: Fri, 27 Sep 2013 11:10:05 +0200 Subject: [PATCH] IB/srp: fix task management handle in srp Currently the srp driver process task manamgement command in wrong way it just ignore the return srp_rsp for successful case eg rsp->status is success, fix this. Signed-off-by: Jack Wang Reviewed-by: Dongsu Park --- drivers/infiniband/ulp/srp/ib_srp.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index f93baf8..5e1f1bf 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -1145,9 +1145,11 @@ static void srp_process_rsp(struct srp_target_port *target, struct srp_rsp *rsp) target->req_lim += be32_to_cpu(rsp->req_lim_delta); spin_unlock_irqrestore(&target->lock, flags); - target->tsk_mgmt_status = -1; - if (be32_to_cpu(rsp->resp_data_len) >= 4) - target->tsk_mgmt_status = rsp->data[3]; + target->tsk_mgmt_status = rsp->status; + if (rsp->flags & SRP_RSP_FLAG_RSPVALID) { + if (be32_to_cpu(rsp->resp_data_len) >= 4) + target->tsk_mgmt_status = rsp->data[3]; + } complete(&target->tsk_mgmt_done); } else { req = &target->req_ring[rsp->tag]; @@ -1739,7 +1741,7 @@ static int srp_send_tsk_mgmt(struct srp_target_port *target, msecs_to_jiffies(SRP_ABORT_TIMEOUT_MS))) return -1; - return 0; + return target->tsk_mgmt_status; } static int srp_abort(struct scsi_cmnd *scmnd) @@ -1776,8 +1778,6 @@ static int srp_reset_device(struct scsi_cmnd *scmnd) if (srp_send_tsk_mgmt(target, SRP_TAG_NO_REQ, scmnd->device->lun, SRP_TSK_LUN_RESET)) return FAILED; - if (target->tsk_mgmt_status) - return FAILED; for (i = 0; i < SRP_CMD_SQ_SIZE; ++i) { struct srp_request *req = &target->req_ring[i]; -- 1.8.4