From patchwork Mon Jul 31 14:26:04 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 1815031 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=wRRvQq/P; dkim-atps=neutral Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4RF0t75ffTz1yfG for ; Tue, 1 Aug 2023 00:26:38 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1qQTqs-0002Lj-04; Mon, 31 Jul 2023 14:26:26 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1qQTqp-0002L9-1r for kernel-team@lists.ubuntu.com; Mon, 31 Jul 2023 14:26:23 +0000 Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) (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 smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 5EF743F71D for ; Mon, 31 Jul 2023 14:26:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1690813581; bh=2XC8w7a3RBfG8gVu5skYacHAAELEOjC//y1mMGv+PK8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=wRRvQq/P2YlS4QHRqWKGfbDM5Nv5uod25e5rcl3rgh0gT9txRLLgIEa+ViHW7l6yB gc4dN/bL65xYK11cymjYSJ/nmKsNYy6EQTmxyOQoZfehSoHS2MtMq13xdYa9TLRw41 3OQLsp2dBx2sdZmtrImtYOzG0DqF6/2qaC9BB4mpANKpOJNDhxA4RDFKRSgS2SqYy9 ABk+RlQK3eUWGPoZ5xq6bNcLAqrm+209l0Ac5qmtoNpKtO9GGia+95d7uxXh6sTGRT pEthwVaP95XGc+kqs9DF3ZkjNGK1qvFxDWlkq/jREvko+3RLDOStEO0FI3gAKGdTEr OtIClZ9xHDk/A== Received: by mail-il1-f200.google.com with SMTP id e9e14a558f8ab-3487b412e41so47025175ab.1 for ; Mon, 31 Jul 2023 07:26:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690813580; x=1691418380; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2XC8w7a3RBfG8gVu5skYacHAAELEOjC//y1mMGv+PK8=; b=Sf9uHO3KbHzVVhP/W7EY6H9sovIsw4v16Vl6UgavSjgbCfrikR89zZ7opPoj17mh/K K5qaj8qIk/lR0lqSORwajTKSLIFd+FP5e1neJnSE6N2ePVjzOKuHE/b5y2KhE+KzpXbL FxJeIWnsiwkjazeZh/qXQvUfV5lyAAVwsiGPnWrssNDkX0d2Sttsoq36xLCxrmG7sR9A RN0esAJmBSPd+o8mCqy08EFbMfF29zIvTbkrHl9V7MLcycz3c20Sko+bPGohhqk2nW6Z X4z0p74fHMzapTWxCmTxbRZ2MtE13RJqa0VrQm4pobj2sPm3Y6Ndcqt2mCNrzFzUHsTN GNFQ== X-Gm-Message-State: ABy/qLaVQHtfFLStIMv8RiSKojhuVNmVcKngN3kg2vdScpWsDtgYX40O orTOW0woU+whfO0Zj4UoNsz58PmWkRgEfi/2j8RoKoyYrlBM+EXZ9xyCt+CuHqfpeL/m7MUC4P5 mVobAFGj5nXH+OG5eNAFssjNwEpcwZEq9O37DSPNYewbupPpa/g== X-Received: by 2002:a05:6e02:1a41:b0:345:cdbe:833c with SMTP id u1-20020a056e021a4100b00345cdbe833cmr9983898ilv.28.1690813579892; Mon, 31 Jul 2023 07:26:19 -0700 (PDT) X-Google-Smtp-Source: APBJJlElQKZ5bm1RIFkCC1h9HzXsJj683RW3z6xkd9EBmWLbb7MHJ7UwI8u4dpLiMpgc2dZTbb9NZw== X-Received: by 2002:a05:6e02:1a41:b0:345:cdbe:833c with SMTP id u1-20020a056e021a4100b00345cdbe833cmr9983885ilv.28.1690813579622; Mon, 31 Jul 2023 07:26:19 -0700 (PDT) Received: from smtp.gmail.com (174-045-099-030.res.spectrum.com. [174.45.99.30]) by smtp.gmail.com with ESMTPSA id b5-20020a92db05000000b00345ffd35a29sm3189360iln.68.2023.07.31.07.26.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Jul 2023 07:26:18 -0700 (PDT) From: Tim Gardner To: kernel-team@lists.ubuntu.com Subject: [PATCH][jammy/linux-azure] cifs: fix mid leak during reconnection after timeout threshold Date: Mon, 31 Jul 2023 08:26:04 -0600 Message-Id: <20230731142605.161455-3-tim.gardner@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230731142605.161455-1-tim.gardner@canonical.com> References: <20230731142605.161455-1-tim.gardner@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Shyam Prasad N BugLink: https://bugs.launchpad.net/bugs/2029138 When the number of responses with status of STATUS_IO_TIMEOUT exceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect the connection. But we do not return the mid, or the credits returned for the mid, or reduce the number of in-flight requests. This bug could result in the server->in_flight count to go bad, and also cause a leak in the mids. This change moves the check to a few lines below where the response is decrypted, even of the response is read from the transform header. This way, the code for returning the mids can be reused. Also, the cifs_reconnect was reconnecting just the transport connection before. In case of multi-channel, this may not be what we want to do after several timeouts. Changed that to reconnect the session and the tree too. Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name MAX_STATUS_IO_TIMEOUT. Fixes: 8e670f77c4a5 ("Handle STATUS_IO_TIMEOUT gracefully") Signed-off-by: Shyam Prasad N Signed-off-by: Steve French (cherry picked from commit 69cba9d3c1284e0838ae408830a02c4a063104bc) Signed-off-by: Tim Gardner --- fs/cifs/connect.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c index b746abd9556f..3792d8a80b58 100644 --- a/fs/cifs/connect.c +++ b/fs/cifs/connect.c @@ -59,7 +59,7 @@ extern bool disable_legacy_dialects; #define TLINK_IDLE_EXPIRE (600 * HZ) /* Drop the connection to not overload the server */ -#define NUM_STATUS_IO_TIMEOUT 5 +#define MAX_STATUS_IO_TIMEOUT 5 struct mount_ctx { struct cifs_sb_info *cifs_sb; @@ -1109,6 +1109,7 @@ cifs_demultiplex_thread(void *p) struct mid_q_entry *mids[MAX_COMPOUND]; char *bufs[MAX_COMPOUND]; unsigned int noreclaim_flag, num_io_timeout = 0; + bool pending_reconnect = false; noreclaim_flag = memalloc_noreclaim_save(); cifs_dbg(FYI, "Demultiplex PID: %d\n", task_pid_nr(current)); @@ -1148,6 +1149,8 @@ cifs_demultiplex_thread(void *p) cifs_dbg(FYI, "RFC1002 header 0x%x\n", pdu_length); if (!is_smb_response(server, buf[0])) continue; + + pending_reconnect = false; next_pdu: server->pdu_size = pdu_length; @@ -1207,10 +1210,13 @@ cifs_demultiplex_thread(void *p) if (server->ops->is_status_io_timeout && server->ops->is_status_io_timeout(buf)) { num_io_timeout++; - if (num_io_timeout > NUM_STATUS_IO_TIMEOUT) { - cifs_reconnect(server, false); + if (num_io_timeout > MAX_STATUS_IO_TIMEOUT) { + cifs_server_dbg(VFS, + "Number of request timeouts exceeded %d. Reconnecting", + MAX_STATUS_IO_TIMEOUT); + + pending_reconnect = true; num_io_timeout = 0; - continue; } } @@ -1257,6 +1263,11 @@ cifs_demultiplex_thread(void *p) buf = server->smallbuf; goto next_pdu; } + + /* do this reconnect at the very end after processing all MIDs */ + if (pending_reconnect) + cifs_reconnect(server, true); + } /* end while !EXITING */ /* buffer usually freed in free_mid - need to free it here on exit */