From patchwork Wed Mar 11 04:36:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve French X-Patchwork-Id: 11430635 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 57BE792A for ; Wed, 11 Mar 2020 04:36:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 27A5C2146E for ; Wed, 11 Mar 2020 04:36:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Bf2mG29H" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726053AbgCKEgk (ORCPT ); Wed, 11 Mar 2020 00:36:40 -0400 Received: from mail-yw1-f46.google.com ([209.85.161.46]:35091 "EHLO mail-yw1-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725379AbgCKEgk (ORCPT ); Wed, 11 Mar 2020 00:36:40 -0400 Received: by mail-yw1-f46.google.com with SMTP id d79so862473ywd.2 for ; Tue, 10 Mar 2020 21:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Sf7tpXoI6VUNj+xA4inq2BQ7+d/qXznFFD7cMKOHJPU=; b=Bf2mG29HXY7lB4675y2Q3GyTX08NmtdU4Pu815EvspLq5+rKgTuMlRP8LQTfqXiwwG mxOQl2J36Jnbi4X9s0w2knn7vDn1dVM9Pfowhjg0Yxyl+12pc6MwXqpyOBKIkSfpEt+y LBTfw+GdK/04HvTWC2sNOW/B8V6kQ4MzJ5MnR8QUU5FBxztLwNbsMRBna2lELeXGpcbm fV207UTUhEJCgUli76dcvF3uhU0bvpbo0Z2qiYc5W9+5RajPreN1PnEAB0FkWCbeCpeq T6iketGVkGwnjRJJc8Qh1g1eYQcU5et8iHF8LoOVEkllEgLPrJPXsxMk87uyfnyrH7ND sUUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Sf7tpXoI6VUNj+xA4inq2BQ7+d/qXznFFD7cMKOHJPU=; b=VoEXX7uY9/EWFJ3hjhYbH3Tm5lKFe8vAUuPg+1x5yqenBousgKJr/AaBdLBl7x5fa+ Eh07rrgGmyTVrbMOY95gAbGcRUyejjdW3HLKtU+m4RYepsoRLX4YnYxbU5v3s0hGkwMr 78O0QNFkvClscQYqMh5Hr2FUQirT9wczW59OhP/uZL9C8ZZWUgdJFWSi0KMKiiJAphRu IDOVikoVl7XuXd9FrIf6zWc6RGTBAum5iql8gG70Pa2BWlHmRaoTJMKN7dy4rgCqnyGy 6stmq+C2/Z2i+eodsKPZtN3PvXXaZ3EJvIxPAO/RUwL+Ork26LfSXpMuFz82hhQvOXv1 a+uQ== X-Gm-Message-State: ANhLgQ2JQx3slirKKR/B6X6bzBex10VfCmaFYf345Y+kpGEyl4kOAiAP kZn1TdifkWH7lgT4X6/bypbBMghdQUBRje+WsxD0Lr19P1Q= X-Google-Smtp-Source: ADFU+vvBookzUM8kc9TlUJq7ItWdu5lM1F+bieJNyiwNSZ96ju9JOvyVYsDqH5LxK6cTu7Nz2hD+gmi5Oavs7lvbaWo= X-Received: by 2002:a25:cf85:: with SMTP id f127mr1056697ybg.167.1583901399085; Tue, 10 Mar 2020 21:36:39 -0700 (PDT) MIME-Version: 1.0 From: Steve French Date: Tue, 10 Mar 2020 23:36:27 -0500 Message-ID: Subject: [PATCH][SMB3] Increment num_remote_opens stats counter even in case of smb2_query_dir_first To: Shyam Prasad N , CIFS Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org Patch from Shyam attached (tentatively merged into cifs-2.6.git for-next). See his description below: The num_remote_opens counter keeps track of the number of open files which must be maintained by the server at any point. This is a per-tree-connect counter, and the value of this counter gets displayed in the /proc/fs/cifs/Stats output as a following... Open files: 0 total (local), 1 open on server ^^^^^^^^^^^^^^^^ As a thumb-rule, we want to increment this counter for each open/create that we successfully execute on the server. Similarly, we should decrement the counter when we successfully execute a close. In this case, an increment was being missed in case of smb2_query_dir_first, in case of successful open. As a result, we would underflow the counter and we could even see the counter go to negative after sufficient smb2_query_dir_first calls. I tested the stats counter for a bunch of filesystem operations with the fix. And it looks like the counter looks correct to me. I also check if we missed the increments and decrements elsewhere. It does not seem so. Few other cases where an open is done and we don't increment the counter are the compound calls where the corresponding close is also sent in the request. Reviewed-by: Aurelien Aptel Reviewed-by: Pavel Shilovsky From f34d2f84852219dd8b252f08773f4e49c3b2db4d Mon Sep 17 00:00:00 2001 From: Shyam Prasad N Date: Mon, 9 Mar 2020 01:35:09 -0700 Subject: [PATCH] CIFS: Increment num_remote_opens stats counter even in case of smb2_query_dir_first The num_remote_opens counter keeps track of the number of open files which must be maintained by the server at any point. This is a per-tree-connect counter, and the value of this counter gets displayed in the /proc/fs/cifs/Stats output as a following... Open files: 0 total (local), 1 open on server ^^^^^^^^^^^^^^^^ As a thumb-rule, we want to increment this counter for each open/create that we successfully execute on the server. Similarly, we should decrement the counter when we successfully execute a close. In this case, an increment was being missed in case of smb2_query_dir_first, in case of successful open. As a result, we would underflow the counter and we could even see the counter go to negative after sufficient smb2_query_dir_first calls. I tested the stats counter for a bunch of filesystem operations with the fix. And it looks like the counter looks correct to me. I also check if we missed the increments and decrements elsewhere. It does not seem so. Few other cases where an open is done and we don't increment the counter are the compound calls where the corresponding close is also sent in the request. Signed-off-by: Shyam Prasad N CC: Stable Signed-off-by: Steve French --- fs/cifs/smb2ops.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c index 83e5b351d5af..ea9fcdca4d20 100644 --- a/fs/cifs/smb2ops.c +++ b/fs/cifs/smb2ops.c @@ -2226,6 +2226,8 @@ smb2_query_dir_first(const unsigned int xid, struct cifs_tcon *tcon, goto qdf_free; } + atomic_inc(&tcon->num_remote_opens); + qd_rsp = (struct smb2_query_directory_rsp *)rsp_iov[1].iov_base; if (qd_rsp->sync_hdr.Status == STATUS_NO_MORE_FILES) { trace_smb3_query_dir_done(xid, fid->persistent_fid, -- 2.20.1