Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp6250659rdb; Thu, 14 Dec 2023 12:30:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IH4CQVIvP83EtOvi7q3FHsqwCg/Kn5IXC67wXVp9s8pJ/9OZtJMJFyIgYgmH8zIb6DGoPaE X-Received: by 2002:a50:9f84:0:b0:552:63ac:2cd1 with SMTP id c4-20020a509f84000000b0055263ac2cd1mr1112747edf.16.1702585832330; Thu, 14 Dec 2023 12:30:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702585832; cv=none; d=google.com; s=arc-20160816; b=DZC0S9/Aj96Se0JXiYVxZD/1FAoZBjMjT32lzpGWciC3vH3hJEejvzijdQFTCnIX9Q Y7d/hNIt+ZorUF3yEB+0tunLsrNl2p0XyuX3BGcRnTY6pHbINcDcKV1ZXGkts/D3Letw KDjVC0xrkydgixHSjq9lEOHnjJlXNXchwfkzKSVSOO/f8MWgV1hYCm8csp5iQF+glXxs vpQOHxhEH+FyytBGiy0c35o/A5+tpIjhI33v8CLf23ENCY7sGjabFWqOvH2fHYzTIUqR urUr0EqqeD3AIYN4jS01kWKVJ7GsVxwtVeDtRWbwSh8mXyYk+crkNtnxrjVXjdOg8iFR +WeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=QXuga73/c/MA5mQD7NNrVlnCLK003+KYeVkn9fwBS0Q=; fh=nEKu+zgQATKPV+Ads2L4s8oHFLEaEL3lj17fdnSLmOU=; b=V9fR3G3jATI0ExO9OxmivpmNg+aYLT6OZrM8y2Djyvr6K8UvPo3G9rvsduGR3Xz7tP qrD489rko2ZP5YKt1fbpjLOTzTAC4/Fg9u/pZLceXbL9YnTYzO//lBX3/xtSkH96Qkzi Zp6u25M+k2BgeKrbOwmLPIaYIgAB7kGU1wdQne9+cxkF14vlWxCrjfoaYXRGI1wHnK6N XPyRlpfQ7UmuRBqdXACOapkbkAXcg0U6ASNYUxP1oL2MRr/C0D4zkubtE+4qP9nsQjP9 NIkp+LkSRiSbGuyb7Oss9DelHPsPxunOOGV9ZT+bmyzAyaccYRCc1Fxel1BtBzMjC5hB 5mug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VVhpfJo2; spf=pass (google.com: domain of linux-kernel+bounces-68-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-68-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id t17-20020a50c251000000b0055223d7990asi1747160edf.218.2023.12.14.12.30.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Dec 2023 12:30:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-68-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VVhpfJo2; spf=pass (google.com: domain of linux-kernel+bounces-68-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-68-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id E36D41F224C3 for ; Thu, 14 Dec 2023 20:30:31 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 52EE46A358; Thu, 14 Dec 2023 20:30:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="VVhpfJo2" X-Original-To: linux-kernel@vger.kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DEA8D6AB98 for ; Thu, 14 Dec 2023 20:30:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702585806; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QXuga73/c/MA5mQD7NNrVlnCLK003+KYeVkn9fwBS0Q=; b=VVhpfJo2kzjJzCy9uf9kfmv1QCp9J72woAgk4m2ZRGT+d0W2pevdKJFw8fCZIzeyBE83FN x3Gb+ZBXEYPkn+klUv99/mi1RSQtG7mkWFAzVppKT2GVNaWpVLmceqER0IgS0xp6VXY07q KX1W/ieKELTlLqzoOvqASdWeqXy2bog= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-26-5RDRj6REPkG2aO5zjCKD4Q-1; Thu, 14 Dec 2023 15:30:02 -0500 X-MC-Unique: 5RDRj6REPkG2aO5zjCKD4Q-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0A11888FBA3; Thu, 14 Dec 2023 20:30:02 +0000 (UTC) Received: from rhel-developer-toolbox-latest (unknown [10.2.17.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3CD052166B31; Thu, 14 Dec 2023 20:30:01 +0000 (UTC) Date: Thu, 14 Dec 2023 12:29:59 -0800 From: Chris Leech To: Lee Duncan Cc: target-devel@vger.kernel.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, dbond@suse.com, hare@suse.de, michael.christie@oracle.com Subject: Re: [PATCH 1/2] scsi: target: iscsi: handle SCSI immediate commands Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 On Wed, Dec 13, 2023 at 05:24:54PM -0800, Lee Duncan wrote: > > > > > @@ -1255,14 +1248,15 @@ int iscsit_process_scsi_cmd(struct iscsit_conn *conn, struct iscsit_cmd *cmd, > > > /* > > > * Check the CmdSN against ExpCmdSN/MaxCmdSN here if > > > * the Immediate Bit is not set, and no Immediate > > > - * Data is attached. > > > + * Data is attached. Also skip the check if this is > > > + * an immediate command. > > > > This comment addition seems redundant, isn't that what the > > "Immediate Bit is not set" already means? > > The spec is confusing with respect to this. The "Immediate Bit" means > an immediate command. These commands are done "now", not queued, and > they do not increment the expected sequence number. > > Immediate data is different, and unfortunately named IMHO. It's when a > PDU supplies the data for the SCSI command in the current PDU instead > of the next PDU. I understand the protocol, just trying to make sense of the implementation and what the existing comment meant. And the existing comment already has two conditions in it, even if the code doesn't. I think I understand now why this is delaying CmdSN validation when there is immediate data, until after the DataCRC can be checked. This comment in iscsit_get_immediate_data, where the delayed processing occurs, also seems to read that "Immediate Bit" is in reference to an immediate command. * A PDU/CmdSN carrying Immediate Data passed * DataCRC, check against ExpCmdSN/MaxCmdSN if * Immediate Bit is not set. but neither of these locations (before these changes) that mention the "Immediate Bit" in the comments actually check for cmd->immediate_cmd. > > > * > > > * A PDU/CmdSN carrying Immediate Data can only > > > * be processed after the DataCRC has passed. > > > * If the DataCRC fails, the CmdSN MUST NOT > > > * be acknowledged. (See below) > > > */ > > > - if (!cmd->immediate_data) { > > > + if (!cmd->immediate_data && !cmd->immediate_cmd) { > > > cmdsn_ret = iscsit_sequence_cmd(conn, cmd, > > > (unsigned char *)hdr, hdr->cmdsn); > > > if (cmdsn_ret == CMDSN_ERROR_CANNOT_RECOVER) > > > > Are you sure this needs to be checking both conditions here? I'm > > struggling to understand why CmdSN checking would be bypassed for > > immediate data. Is this a longstanding bug where the condition should > > have been on immediate_cmd (and only immediate_cmd) instead? > > The immediate data check was there already, and there haven't been any > bugs I know of, so I assumed that part of the code was ok. > > > > > Or is this because of the handling the immediate data with DataCRC case > > mentioned? I do see iscsit_sequence_cmd also being called in > > iscsit_get_immediate_data. > > I will check that but I suspect you are correct. Is it correct to skip all of iscsit_sequence_cmd for an immediate command here? You are already skipping iscsit_check_received_cmdsn inside iscsit_sequence_cmd in this patch. If cmd->immediate_cmd is set, where does iscsit_execute_cmd now get called from? - Chris Leech