From nobody Mon Jan 03 19:21:12 2022 X-Original-To: scsi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CC402192CB07 for ; Mon, 3 Jan 2022 19:21:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSQZx4r3wz3hY7; Mon, 3 Jan 2022 19:21:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 140D820D64; Mon, 3 Jan 2022 19:21:12 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <6c6a7236-3f54-efcf-7996-9e6c796bf5f0@FreeBSD.org> Date: Mon, 3 Jan 2022 11:21:12 -0800 List-Id: SCSI subsystem List-Archive: https://lists.freebsd.org/archives/freebsd-scsi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: Alexander Motin Cc: =?UTF-8?Q?Edward_Tomasz_Napiera=c5=82a?= , scsi@FreeBSD.org, Ken Merry References: <42e175d9-1693-29e2-0b5b-3fa513aa2a2d@FreeBSD.org> <7f1a1a65-199d-858a-792c-42871d1df13e@FreeBSD.org> <68ad0ffd-79fb-973d-e5ba-92deee352d44@FreeBSD.org> <2ce80c64-6954-21d0-74eb-eeb88e289350@FreeBSD.org> <10687910-7500-008c-aed5-61f76ae90b3d@FreeBSD.org> <1df3d9cf-6456-bcff-4fbe-c36136692efa@FreeBSD.org> <253e4d65-4c24-20be-480d-026c35d10ae5@FreeBSD.org> <5f5eac1f-7581-c19d-b2a3-ccf927471cca@FreeBSD.org> From: John Baldwin Subject: Re: iSCSI target: Handling in-flight requests during ctld shutdown In-Reply-To: <5f5eac1f-7581-c19d-b2a3-ccf927471cca@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641237673; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qj+hur+STOkygjDxP7aoQWX44cHS3MB55mB+OjiuG70=; b=nyuatLLEt7rq++hSq0pl4H3eR5wLPq/ZCN1e56Pu/YN84rtGzl9/lI4EqtsoFSdc6zQOTe chJykICacCbBywwv1err4shBnBFqPX9eYj4jm5LEZCBUXQRac3DTLuyA7uaJfHTxVsfQBi cnhBn5aWvYFwmX7YTQZ/QiMKkAjhwlGqt6tRiFQHrORx+k5OKu3q3PNiqad5GzE09ldUrG SN2Zk/DeNd7tpECiAtFC3X4KdJ2ZzjQhQO4RIDgQFCTRHDsbyQY2QKbFpv2LP22l3pPh3t xMIpkNjkGSF9xxuzjy109rJ5kGSaJimbLvq308NeELQ2tpu2fWPKyzm8vWIl5g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641237673; a=rsa-sha256; cv=none; b=Y59egFCVp6wuTtBhLPdgApJT+f9SeFBEnfXaT8jsR4yMJCcdFl8Z8DFpvh7bog3CwJ9Mx6 6iHC7CzOjuHPUBPg/vf4nk6rJIpu5kRPW+W6EGXpMsxxCmTdJ0JgHvATT3UjNfoCsV9Chq 5cfzoh+HWCrS71wfGQXw8WobAyoLHtpqhmLx8xv5yDCuaBCJT4xNQyyi8qI+USlcDenW5L FABR2v2GorNukHIIuBQQFIs2pO2EKRBLuisXHg3x9pqsIdPd2Zo6ldpjsScGUCV3GrIQqV pYOZtK6NRDbDZ0dTQOdX4Ys7ylbzCG2qhMP3uCGFOVtqukkB8GO1vRrAuU/fzg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/31/21 3:07 PM, Alexander Motin wrote: > On 31.12.2021 17:17, John Baldwin wrote: >> So my remaining question I guess is if I add a new >> 'cs->cs_terminating_tasks' >> or the like, how does cfiscsi_datamove_out ensure that no response is sent? > > By the time cs_terminating_tasks is set, there is no connection any > more, so nothing will be sent any way. The problem with cs_terminating > is that it is set too early, when connection may still be alive. Ok. > On top of that, probably not important, but CTL_TASK_I_T_NEXUS_RESET > call by cfiscsi_session_terminate_tasks() will make the code below to > also block the status reporting for the most commands. Well, this was more about if there are potential commands (perhaps in the future) that get aborted in cfiscsi_datamove_out that weren't cancelled by CTL_TASK_I_T_NEXUS_RESET due to not being on the OOA queue. However, I think we agree that currently those shouldn't exist. Perhaps I can just assert that CTL_FLAG_ABORT is set. >> The only thing I've seen so far is this code in cfiscsi_scsi_command_done: >> >>     /* >>      * Do not return status for aborted commands. >>      * There are exceptions, but none supported by CTL yet. >>      */ >>     if (((io->io_hdr.flags & CTL_FLAG_ABORT) && >>          (io->io_hdr.flags & CTL_FLAG_ABORT_STATUS) == 0) || >>         (io->io_hdr.flags & CTL_FLAG_STATUS_SENT)) { >>         ctl_free_io(io); >>         icl_pdu_free(request); >>         return; >>     } >> >> Would you prefer checking cs_terminating_tasks in this function as well to >> avoid sending the peudo-aborted responses instead of forcing CTL_FLAG_ABORT >> on? > > CTL_FLAG_ABORT flags there are correct. The tasks are really aborted. > But if I remember it right, CTL_TASK_I_T_NEXUS_RESET should not set > CTL_FLAG_ABORT_STATUS, so abort statuses should not be sent. Abort > statuses are only sent when initiator does not expect aborts, for > example, when some other initiator requested LUN or target reset. I was more asking about the potential future use case of there being a command we data abort that doesn't already have CTL_FLAG_ABORT set, but just asserting it is already set it perhaps the simplest approach instead. -- John Baldwin