From nobody Fri Dec 31 23:07:40 2021 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 0B2661910B8A for ; Fri, 31 Dec 2021 23:07:49 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQglm6fLqz4tNG; Fri, 31 Dec 2021 23:07:48 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qt1-x833.google.com with SMTP id f9so25168402qtk.4; Fri, 31 Dec 2021 15:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TniNcgjwkzraxBuiOz8Iw7JYyi0luhgoKmy+Ve4nrdM=; b=ZlLOzUZlPJtInbl43Y3Uu1asySYcqKrYBPMLQXC/Toofx8vu+9/AugBRsMejDM5xZR iV3eq9GjDoI9iCzVLD9Yx0sIIcIf7f9t9tTn1Hr/HK5PHWPIJ2TQJk4Bcgur0ELqvat+ r3QKmt5QDf4TaxyLHRKLip4iEinR9PAkOkVNHRhh0PE83EtlEtAtoscFBiVFdn5a3F/Z SMMuKB2ACksX42G4drst8s7SOLhqRAP6vWNhU4GLCBxelF9pR77K1RSdP07XyD92IFTk yN+R+4nyJMREXMBKZw8dlGBpjxaS0gPXtEVom7yUUjtTp9RmxU+9TUvqHPYTOo2lZ51K IalA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TniNcgjwkzraxBuiOz8Iw7JYyi0luhgoKmy+Ve4nrdM=; b=yQbtBW4SsxzrXeB6nIgYxPZsl+7yFQHK0DpM56VprXZVjCT7QySfHRTC1zOWkf5q4m DTIukLfs2r5qg1NYB25NISs4SyOgFJRgGFuYoL7qB7t9f9/iXZJK8OaAcXPJBV3/R7oh 6bzg4MwjPIIPmW0Wm/dpZeJIec9/l4ctNOaZK38yvcORXbi+vpTFZzXjo1DAxYbxMzyn tsdlXwBm5IHDY0MSPZ3dTbDhNn8dUHpwcCqVn9cy++B8tXK91bd7Y/rDhP23ZeTVG67x cz9VURB5RBucVyUFVVg9aUijju2zCqIF+DPVqtJLiMkcMkDi0/BLHd2ui7oAEjsu3oG6 1+vg== X-Gm-Message-State: AOAM5339h2gxWxHAziX5B7/o5h9g1y5PVw6TdKwFe1glXYdiQgtNldsQ Fc1qbIyNoR2CzdU/I/8qFlxi6aGpVgk= X-Google-Smtp-Source: ABdhPJxXetXpneq7aEBQeOO3NrFpdVHM3oInWbCkwCDKxbPNOb3cSX+rHF9cywHZ+PwV2LbQrYGo+w== X-Received: by 2002:ac8:5704:: with SMTP id 4mr214466qtw.629.1640992061725; Fri, 31 Dec 2021 15:07:41 -0800 (PST) Received: from spectre.mavhome.dp.ua (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id l15sm22254040qkp.16.2021.12.31.15.07.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Dec 2021 15:07:41 -0800 (PST) Subject: Re: iSCSI target: Handling in-flight requests during ctld shutdown To: John Baldwin 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> From: Alexander Motin Message-ID: <5f5eac1f-7581-c19d-b2a3-ccf927471cca@FreeBSD.org> Date: Fri, 31 Dec 2021 18:07:40 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 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 In-Reply-To: <253e4d65-4c24-20be-480d-026c35d10ae5@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JQglm6fLqz4tNG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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. 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. > 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. -- Alexander Motin