Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8975892ybi; Tue, 23 Jul 2019 19:17:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqyqxPrjFqkxIW9SVlDplnzCdLt/xNYYbg4BJ44kG4JnoSgBhMSpxIb0LtE0QK16rdK1/UrI X-Received: by 2002:a17:902:124:: with SMTP id 33mr85398409plb.145.1563934630965; Tue, 23 Jul 2019 19:17:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563934630; cv=none; d=google.com; s=arc-20160816; b=kojlXOkkv4ZSa4GcqBTaMrQiLfwGl0H9Zx1wI38e1Sj6YAdycFRz1kr6PkGJoS9O+/ 7NVJt+6I4jT2jQq7d9J7AXcl2H9t4DhQ+/BvJXUSJ7NO54ub33LdjkGzSMWMMIwnRgoQ 7yrweQ0n3swMAnU6Ai3plGX/yAC8LbvuM1z9n/Clg6bdONkZLYb9TmFpkc9+jyrJUB2W zDoSxyCWzYM1i7IdBPw2G0vzBTlfwLoqEAUKdDUZ7gGzaXxS8PoZKFBabxNqSbRZGa49 WvbUnI+MVUP9+n5Q2eRduqDLISWaWq/BmNCCHmdg178HEoRdvOvru0TrBSNhqBBcod/h gBCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=w9+ZmzMTvq2iSo2ujhpLGpBEFet1WMn1gqo2dfrjb/E=; b=Ok2ulabCS7Wh2iYlyuxDo7g8zCRG99kXfAKyCgEEW8k2VAIkl1O7G+9AgnTCfVvL2R 6I4jlLzZp3ija/Qzl5SNeqbagUVsSTZrl4ba7LZiBzQagIcQp3GjBP7BZMozvL/villD X1QNiHl9LHDnnkWeDizpFerqpwFNsGve+KbYIV7nRrAgHpgtHm130XekdhjKfRKCB80C c+qFd3ru2fnIsMR/N6gvZ28FrQmo6TTIA6NlCtI417QYfRrf8y+i0R34zClxdWXystyD TsYzrxLUoVjNh0Csl+niiwwZYV746GhrCVc6YNC8nLS5i26XjwtFV+LbId+ttZSv8IGs Pr4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MSNTvFrZ; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j1si15850423pfa.91.2019.07.23.19.16.55; Tue, 23 Jul 2019 19:17:10 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MSNTvFrZ; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390287AbfGWNeE (ORCPT + 99 others); Tue, 23 Jul 2019 09:34:04 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:46366 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732718AbfGWNeC (ORCPT ); Tue, 23 Jul 2019 09:34:02 -0400 Received: by mail-pl1-f193.google.com with SMTP id c2so20601502plz.13; Tue, 23 Jul 2019 06:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=w9+ZmzMTvq2iSo2ujhpLGpBEFet1WMn1gqo2dfrjb/E=; b=MSNTvFrZdBuTkcv6J2c6zOvMJXPHLl2nsaaSqrUy2hsatnWGr5v3RhzF5Qv/2HSSoB FiBL0ucr8akcV/auBmb36ZqMaEXHkmF4I9TXRksG6QZFRIrha8lxDGZPIi7fxrsOPKTq M97+AkClcvMWEMYg2e5hfjhbZ76x6Wh3yhCue68czqoOL4Ao0Pz1QNtmxzYfrjf+97OB BjFyvKFbrj6zwXH4VDAjgNDoG6t0ylgO90UrUYG85x036+ywDTX+n3KkSf956+vhYweo 7i6xIGGN//Fo5oWiCyXJF94IA4Fl25mbT576y+Xi5A3MN8SBr4RhhnXDPslisLwvCzDc Ocpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=w9+ZmzMTvq2iSo2ujhpLGpBEFet1WMn1gqo2dfrjb/E=; b=etZO09hmND/Lt2V9jUXVkvxO6NW52S4dJlwqNxbCUnvVv4gJJOHcrlCeD0hoifD/wp /OInGoBk4CTkD4/9+EOc2KSJvDh3sDF8maDMukAvvTT2GEpdM/wm2EvQB5hbghhG7Bdf hG/LVnU7PU1I7rFp/LnoFTAotpV7CtCJyBZaSK1mFa/6E3qqbvSjbL5t03b/aq3oncj2 I9o3R+lzM3xa2x5asFzUPiKlYNGnfpzgJI1Ju2rxjytWByBfuAdHhRAAvSLgSJBhLOPN U5yY5mFipX5eS6HIrHxrVa04G8uC43y2jnlPcOoXxscYa8fojyExGMJNR62IcQzOBHmH G8Fw== X-Gm-Message-State: APjAAAVQbdL0BhGmISyA8WSfP2TUPlCLvuf42bedqY3kJ8q3jQmgTHRn t8PDgCZ0R1cyMxEtE0YWyw0= X-Received: by 2002:a17:902:f216:: with SMTP id gn22mr78826259plb.118.1563888841134; Tue, 23 Jul 2019 06:34:01 -0700 (PDT) Received: from localhost ([123.213.206.190]) by smtp.gmail.com with ESMTPSA id h26sm46900292pfq.64.2019.07.23.06.33.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 23 Jul 2019 06:34:00 -0700 (PDT) Date: Tue, 23 Jul 2019 22:33:58 +0900 From: Minwoo Im To: Sreekanth Reddy , Hannes Reinecke Cc: minwoo.im@samsung.com, "sathya.prakash@broadcom.com" , "suganath-prabu.subramani@broadcom.com" , "jejb@linux.ibm.com" , "martin.petersen@oracle.com" , "MPT-FusionLinux.pdl@broadcom.com" , "linux-kernel@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "linux-block@vger.kernel.org" , Euihyeok Kwon , Sarah Cho , Sanggwan Lee , Gyeongmin Nam , Sungjun Park , Minwoo Im Subject: Re: [PATCH V2] mpt3sas: support target smid for [abort|query] task Message-ID: <20190723133358.GB7148@minwoo-desktop> References: <20190714034415epcms2p25f9787cb71993a30f58524d2f355b543@epcms2p2> <860cc8cf-6419-c649-b2d9-19b82f6ebc99@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19-07-23 16:57:49, Sreekanth Reddy wrote: > On Mon, Jul 15, 2019 at 11:43 AM Hannes Reinecke wrote: > > > > On 7/14/19 5:44 AM, Minwoo Im wrote: > > > We can request task management IOCTL command(MPI2_FUNCTION_SCSI_TASK_MGMT) > > > to /dev/mpt3ctl. If the given task_type is either abort task or query > > > task, it may need a field named "Initiator Port Transfer Tag to Manage" > > > in the IU. > > > > > > Current code does not support to check target IPTT tag from the > > > tm_request. This patch introduces to check TaskMID given from the > > > userspace as a target tag. We have a rule of relationship between > > > (struct request *req->tag) and smid in mpt3sas_base.c: > > > > > > 3318 u16 > > > 3319 mpt3sas_base_get_smid_scsiio(struct MPT3SAS_ADAPTER *ioc, u8 cb_idx, > > > 3320 struct scsi_cmnd *scmd) > > > 3321 { > > > 3322 struct scsiio_tracker *request = scsi_cmd_priv(scmd); > > > 3323 unsigned int tag = scmd->request->tag; > > > 3324 u16 smid; > > > 3325 > > > 3326 smid = tag + 1; > > > > > > So if we want to abort a request tagged #X, then we can pass (X + 1) to > > > this IOCTL handler. Otherwise, user space just can pass 0 TaskMID to > > > abort the first outstanding smid which is legacy behaviour. > > > > > > Cc: Sreekanth Reddy > > > Cc: Suganath Prabu Subramani > > > Cc: Sathya Prakash > > > Cc: James E.J. Bottomley > > > Cc: Martin K. Petersen > > > Cc: MPT-FusionLinux.pdl@broadcom.com > > > Signed-off-by: Minwoo Im > > > --- > > > drivers/scsi/mpt3sas/mpt3sas_ctl.c | 12 ++++++++++-- > > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c b/drivers/scsi/mpt3sas/mpt3sas_ctl.c > > > index b2bb47c14d35..f6b8fd90610a 100644 > > > --- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c > > > +++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c > > > @@ -596,8 +596,16 @@ _ctl_set_task_mid(struct MPT3SAS_ADAPTER *ioc, struct mpt3_ioctl_command *karg, > > > if (priv_data->sas_target->handle != handle) > > > continue; > > > st = scsi_cmd_priv(scmd); > > > - tm_request->TaskMID = cpu_to_le16(st->smid); > > > - found = 1; > > > + > > > + /* > > > + * If the given TaskMID from the user space is zero, then the > > > + * first outstanding smid will be picked up. Otherwise, > > > + * targeted smid will be the one. > > > + */ > > > + if (!tm_request->TaskMID || tm_request->TaskMID == st->smid) { > > > + tm_request->TaskMID = cpu_to_le16(st->smid); > > > + found = 1; > > > + } > > > } > > > > > > if (!found) { > > > > > I think this is fundamentally wrong. > > ABORT_TASK is used to abort a single task, which of course has to be > > known beforehand. If you don't know the task, what exactly do you hope > > to achieve here? Aborting random I/O? > > Or, even worse, aborting I/O the driver uses internally and corrupt the > > internal workflow of the driver? > > > > We should simply disallow any ABORT TASK from userspace if the TaskMID > > is zero. And I would even argue to disabllow ABORT TASK from userspace > > completely, as the smid is never relayed to userland, and as such the > > user cannot know which task should be aborted. > > Hannes, > > This interface was added long time back in mpt2sas driver and I don't > have exact reason of adding this interface at that time. > But I know that this interface is still used by BRCM test team & few > customers only for some functionality and regression testing. Actually I have sent this patch for the testing purpose for the SAS storage that I'm working with now. Some of test platform could figure out which command has to be aborted or queried via debugfs and information from the device itself with some other methods. If the mpt3sas driver supports the targeted TMF for a single command, then it would be great for the testing. Thanks, Minwoo Im