get:
Show a patch.

patch:
Update a patch.

put:
Update a patch.

GET /api/patches/2224035/?format=api
HTTP 200 OK
Allow: GET, PUT, PATCH, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "id": 2224035,
    "url": "http://patchwork.ozlabs.org/api/patches/2224035/?format=api",
    "web_url": "http://patchwork.ozlabs.org/project/linux-cifs-client/patch/20260416151839.3315696-1-charsyam@gmail.com/",
    "project": {
        "id": 12,
        "url": "http://patchwork.ozlabs.org/api/projects/12/?format=api",
        "name": "Linux CIFS Client",
        "link_name": "linux-cifs-client",
        "list_id": "linux-cifs.vger.kernel.org",
        "list_email": "linux-cifs@vger.kernel.org",
        "web_url": "",
        "scm_url": "",
        "webscm_url": "",
        "list_archive_url": "",
        "list_archive_url_format": "",
        "commit_url_format": ""
    },
    "msgid": "<20260416151839.3315696-1-charsyam@gmail.com>",
    "list_archive_url": null,
    "date": "2026-04-16T15:18:39",
    "name": "[v2] smb/client: fix chan_max and UNC state corruption in smb3_reconfigure",
    "commit_ref": null,
    "pull_url": null,
    "state": "new",
    "archived": false,
    "hash": "cd012cc86eb974c3a396bbab4bf83faf901f4e9c",
    "submitter": {
        "id": 93166,
        "url": "http://patchwork.ozlabs.org/api/people/93166/?format=api",
        "name": "CharSyam",
        "email": "charsyam@gmail.com"
    },
    "delegate": null,
    "mbox": "http://patchwork.ozlabs.org/project/linux-cifs-client/patch/20260416151839.3315696-1-charsyam@gmail.com/mbox/",
    "series": [
        {
            "id": 500178,
            "url": "http://patchwork.ozlabs.org/api/series/500178/?format=api",
            "web_url": "http://patchwork.ozlabs.org/project/linux-cifs-client/list/?series=500178",
            "date": "2026-04-16T15:18:39",
            "name": "[v2] smb/client: fix chan_max and UNC state corruption in smb3_reconfigure",
            "version": 2,
            "mbox": "http://patchwork.ozlabs.org/series/500178/mbox/"
        }
    ],
    "comments": "http://patchwork.ozlabs.org/api/patches/2224035/comments/",
    "check": "pending",
    "checks": "http://patchwork.ozlabs.org/api/patches/2224035/checks/",
    "tags": {},
    "related": [],
    "headers": {
        "Return-Path": "\n <linux-cifs+bounces-10864-incoming=patchwork.ozlabs.org@vger.kernel.org>",
        "X-Original-To": [
            "incoming@patchwork.ozlabs.org",
            "linux-cifs@vger.kernel.org"
        ],
        "Delivered-To": "patchwork-incoming@legolas.ozlabs.org",
        "Authentication-Results": [
            "legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=EM3OZla3;\n\tdkim-atps=neutral",
            "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.105.105.114; helo=tor.lore.kernel.org;\n envelope-from=linux-cifs+bounces-10864-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)",
            "smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=\"EM3OZla3\"",
            "smtp.subspace.kernel.org;\n arc=none smtp.client-ip=209.85.214.182",
            "smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com",
            "smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=gmail.com"
        ],
        "Received": [
            "from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxMDC4YDqz1yCv\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 17 Apr 2026 01:21:15 +1000 (AEST)",
            "from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 90DC7306D1E2\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 16 Apr 2026 15:18:54 +0000 (UTC)",
            "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id CF6D43E3C5A;\n\tThu, 16 Apr 2026 15:18:53 +0000 (UTC)",
            "from mail-pl1-f182.google.com (mail-pl1-f182.google.com\n [209.85.214.182])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 66C2C3E3C5E\n\tfor <linux-cifs@vger.kernel.org>; Thu, 16 Apr 2026 15:18:48 +0000 (UTC)",
            "by mail-pl1-f182.google.com with SMTP id\n d9443c01a7336-2a8720818aeso9085095ad.1\n        for <linux-cifs@vger.kernel.org>;\n Thu, 16 Apr 2026 08:18:48 -0700 (PDT)",
            "from ser8.. ([221.156.231.192])\n        by smtp.gmail.com with ESMTPSA id\n d2e1a72fcca58-82f738b399bsm3621805b3a.8.2026.04.16.08.18.43\n        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n        Thu, 16 Apr 2026 08:18:46 -0700 (PDT)"
        ],
        "ARC-Seal": "i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776352733; cv=none;\n b=HcUM3tnwLfgfABzy6xu9LlKhmJRvzYvVeHcJc89oBVAreEmHQZ+YOg/D207UG8EgcudHaBgwWiq4o0P4xzRFJasjVgppCkE0vqz+qSwfYRfMZitM0y97uqfuR1gAd8/9d8ZkLOLfYka1rfRTXkYCMeg5Bk2+UBj3ohuJP6M/meo=",
        "ARC-Message-Signature": "i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776352733; c=relaxed/simple;\n\tbh=UP/CiVunTonaDGV2Qb9WrDEG4j4D1k7GnPOUnbdyL+E=;\n\th=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:\n\t MIME-Version;\n b=tYqb8Qdw/s8mU/0jq4QIZcG24xqlI4rMRXu3NTMN1nIRRHIQ6Gvl1GKhkzn9BMmjHpoPXM6u0GJnj5q2TcVmZLBO9EM68nIb3LB5NRwnL1Ye8B76NAli6nA5E0xjtH4aUWvtBNkuIDbHTDt9ku0u6SgisS99WnVVPWkKY+MNkuI=",
        "ARC-Authentication-Results": "i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com;\n spf=pass smtp.mailfrom=gmail.com;\n dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=EM3OZla3; arc=none smtp.client-ip=209.85.214.182",
        "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=gmail.com; s=20251104; t=1776352727; x=1776957527;\n darn=vger.kernel.org;\n        h=content-transfer-encoding:mime-version:references:in-reply-to\n         :message-id:date:subject:cc:to:from:from:to:cc:subject:date\n         :message-id:reply-to;\n        bh=hWJmbnMs6FnG4pSZO72MK1KEQtYpxvt77pS90kFtv28=;\n        b=EM3OZla3nSv8k1WA8UIi9fx2vpAZ7EQMtquTGB/on1WDdXLNPdJ+vBOn+eQvxQU7nG\n         QZKYVk93yhxsz98UtHnv9bUnfa/i5Hlgb2kmi4WSY37HGk68w0PeBcs/WJFce8sLnRir\n         Q81PERMD9yhzMGYiGJnXU/4tIOMBoPIxswcenz5BjljE+04STYWVeLSbjjg6wJvfCEt5\n         KpIKPXCI9vHnnq/L+uD7JHEi+adKK7caiw5++ZObs0k89u9SZY8Qfl17MvM+8Qm8AVo7\n         xiM1Ix6z/yYCckhLfkehX97t8k467CB658Gi60JDzJ15kGb6AP4eZIdAiWdkJgmPKQjR\n         P9Kw==",
        "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=1e100.net; s=20251104; t=1776352727; x=1776957527;\n        h=content-transfer-encoding:mime-version:references:in-reply-to\n         :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from\n         :to:cc:subject:date:message-id:reply-to;\n        bh=hWJmbnMs6FnG4pSZO72MK1KEQtYpxvt77pS90kFtv28=;\n        b=kKrzyS2LQ8MvXaOrOYTn+icN2TS/PqHyAWCM+05PXBaveqEwiP7WUqEXq9N6cWLmv5\n         X764GjGHHmwsxq5dAUzh/UW+Jh6aZGN5+8UIE2N/9/EVpi26fsleROuQYHjZjbI2d6dc\n         P2FPSHEZmlnpHX09xzJvEP6wgKfnvcFDPVdRWWyNXhfXLVwKy09CblVeAv11upn97Rju\n         A9JA7UZVF1ptKsrfRk9G949rBMeb05Q3GZ+0C062fOoi++aLg25P/nMqTOmIBhkrbCG3\n         +O3CSCoNlfsjw5rwlhHOhGRn7fA6bAR8PGtHCYNuI7TIBA7RgxEfcU3+eAvdIoVvI6yv\n         Rkcw==",
        "X-Forwarded-Encrypted": "i=1;\n AFNElJ/s8X3kJ2ruKmelq6qtGzJOj/nwHPumBjgRXwlRLDTW/SveVlyCeRDcMJ9nkAOxTBguBfy5rH52YeUn@vger.kernel.org",
        "X-Gm-Message-State": "AOJu0Yz1GOnc0MCluq5dpZJ65ynsdSt4IljWWeZWb+GpMjiLlTuJjdsQ\n\tWVm2rL8Hk4ke8J/WXg2RJVgT0jzHY47BLLQqHwfP8eVBxspXgQt0gGqn",
        "X-Gm-Gg": "AeBDieskjS46lbEUwaK0GOh0wCxpBq1RNB+aLDhMx/nw/cwrGMlAA0+fqV6hQ92hHlF\n\t19k+LdjjZqy+0qh4IQNWCVbqru6VaG/CDx7ag56csdsIPxBYszC/uSsJPNx9Ve1/np0Kd46PC1a\n\tLtjpTwkG3X/y0VxlDD0ypO8IrjhDJB5J7il6t5Rqb9gxzatNOiIbNS2myq9+MxfNTaDQL2rc7DE\n\t0xerPe0ze0MT7iiCN9zEzFDJwplAb/Wgys1RlXShwP/5wUc92rBIfHxqAfIBwZsCbEZSZT6DRH7\n\tx5J3MYFtUQjMS6gg9bdCsQW9GDKxxZggah0/om+KZMqlx8bdHuf2qC04VSoWBFQoTKf8OkFqPcO\n\tCQfVrHamrgoXsyLisgU0QVMzFaF7OMat581TJ9pB6rSf2hBz+115a+2Vf1sOZgYVz1P+dAIY0v2\n\tmJRNdp0nXdSWn++Fj7",
        "X-Received": "by 2002:a05:6a00:3d4f:b0:824:9f50:83c7 with SMTP id\n d2e1a72fcca58-82f7bde2cb1mr1700921b3a.0.1776352726884;\n        Thu, 16 Apr 2026 08:18:46 -0700 (PDT)",
        "From": "DaeMyung Kang <charsyam@gmail.com>",
        "To": "sfrench@samba.org",
        "Cc": "pc@manguebit.org,\n\tronniesahlberg@gmail.com,\n\tsprasad@microsoft.com,\n\ttom@talpey.com,\n\tbharathsm@microsoft.com,\n\trajasimandalos@gmail.com,\n\trajasimandal@microsoft.com,\n\tlinux-cifs@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org,\n\tDaeMyung Kang <charsyam@gmail.com>",
        "Subject": "[PATCH v2] smb/client: fix chan_max and UNC state corruption in\n smb3_reconfigure",
        "Date": "Fri, 17 Apr 2026 00:18:39 +0900",
        "Message-ID": "<20260416151839.3315696-1-charsyam@gmail.com>",
        "X-Mailer": "git-send-email 2.43.0",
        "In-Reply-To": "<20260416022811.2692096-1-charsyam@gmail.com>",
        "References": "<20260416022811.2692096-1-charsyam@gmail.com>",
        "Precedence": "bulk",
        "X-Mailing-List": "linux-cifs@vger.kernel.org",
        "List-Id": "<linux-cifs.vger.kernel.org>",
        "List-Subscribe": "<mailto:linux-cifs+subscribe@vger.kernel.org>",
        "List-Unsubscribe": "<mailto:linux-cifs+unsubscribe@vger.kernel.org>",
        "MIME-Version": "1.0",
        "Content-Transfer-Encoding": "8bit"
    },
    "content": "smb3_reconfigure() has four related bugs when handling a\nmultichannel remount that leave ses->chan_max or cifs_sb->ctx\ninconsistent with the actual state.\n\n1) smb3_sync_ses_chan_max() is called before acquiring\n   CIFS_SES_FLAG_SCALE_CHANNELS. If a concurrent operation (e.g.\n   smb2_reconnect) holds the flag, the current thread takes the\n   loser path and returns -EINVAL, but ses->chan_max has already\n   been updated to the new value. chan_max is then inconsistent\n   with the actual channel state.\n\n2) When smb3_update_ses_channels() fails, ses->chan_max is not\n   rolled back and the error is not propagated to the caller.\n   mount returns success even though the channel configuration\n   was not applied, and repeated failures cause chan_max to\n   drift further from reality.\n\n3) Earlier in smb3_reconfigure(), STEAL_STRING moves UNC, source\n   and username from cifs_sb->ctx into ctx, setting\n   cifs_sb->ctx->UNC to NULL until smb3_fs_context_dup() copies\n   them back near the end of the function. Both the existing\n   CIFS_SES_FLAG_SCALE_CHANNELS loser-path 'return -EINVAL' and a\n   naive 'if (rc < 0) return rc;' to propagate the failure above\n   exit in this window. A single failed multichannel remount\n   therefore permanently nulls cifs_sb->ctx->UNC; /proc/mounts\n   shows the device as \"none\" and every subsequent\n   mount.cifs-based remount is rejected by\n   smb3_verify_reconfigure_ctx() because mount.cifs passes that\n   \"none\" back as the new UNC.\n\n4) If the multichannel update fails but smb3_fs_context_dup() is\n   still allowed to run with the new ctx values, the rejected\n   new max_channels is written into cifs_sb->ctx, undoing the\n   ses->chan_max rollback from (2) and creating a fresh\n   cifs_sb->ctx vs ses->chan_max mismatch.\n\nFix all four by:\n - Moving smb3_sync_ses_chan_max() after the SCALE_CHANNELS\n   acquire so the loser path cannot corrupt chan_max.\n - Capturing old_chan_max before the sync and restoring it on\n   failure while still holding SCALE_CHANNELS so a concurrent\n   reconfigure cannot race with the rollback.\n - Recording any multichannel-path failure in a local mchan_rc\n   and routing it through a common 'out:' label so every exit\n   reaches smb3_fs_context_dup() and cifs_sb->ctx is restored.\n - Before the dup, restoring ctx->multichannel and\n   ctx->max_channels from cifs_sb->ctx on mchan_rc so the dup\n   does not desync cifs_sb->ctx from the already-rolled-back\n   ses->chan_max.\n - Returning mchan_rc to userspace so a failed scaling remount\n   surfaces as an error.\n - Surfacing smb3_fs_context_dup() failure in preference to\n   mchan_rc when both occur. The dup is the final step of the\n   ctx restore and runs after smb3_cleanup_fs_context_contents()\n   has already freed cifs_sb->ctx's strings, so a dup failure\n   (e.g. -ENOMEM) leaves cifs_sb->ctx partially restored with\n   some strings still NULL. Reporting the scaling error in that\n   case would hide the real recovery status from userspace;\n   reporting the dup error exposes it so the caller can react\n   accordingly.\n\nNote: smb3_reconfigure() is not fully transactional. Credentials\n(ses->password and ses->password2) are committed before the\nmultichannel block, so a failed multichannel remount can still\nleave ses->password updated while reporting an error to\nuserspace. Making the entire function atomic is a larger\nrefactor and is left for a separate patch.\n\nTested with a QEMU VM (ksmbd + cifs) using module-parameter-based\nfault injection:\n - Forced smb3_update_ses_channels() failure via module param\n   and verified ses->chan_max is preserved at the old value\n   after remount failure.\n - Pre-set CIFS_SES_FLAG_SCALE_CHANNELS before entering the\n   scaling path and verified the loser path returns -EINVAL\n   without corrupting ses->chan_max.\n - Repeated 19 forced-failure remounts with varying max_channels\n   (range 2-8) and confirmed no chan_max drift.\n - After each failure path, verified /proc/mounts continues to\n   show the original UNC (//127.0.0.1/share) so subsequent\n   remounts are accepted.\nAll scenarios pass with the patch and fail without it.\n\nReported-by: RAJASI MANDAL <rajasimandalos@gmail.com>\nCloses: https://lore.kernel.org/lkml/CAEY6_V1+dzW3OD5zqXhsWyXwrDTrg5tAMGZ1AJ7_GAuRE+aevA@mail.gmail.com/\nFixes: ef529f655a2c (\"cifs: client: allow changing multichannel mount options on remount\")\nSigned-off-by: DaeMyung Kang <charsyam@gmail.com>\n---\n fs/smb/client/fs_context.c | 48 ++++++++++++++++++++++++++++++++------\n 1 file changed, 41 insertions(+), 7 deletions(-)",
    "diff": "diff --git a/fs/smb/client/fs_context.c b/fs/smb/client/fs_context.c\nindex b9544eb0381b..9efd73ce6910 100644\n--- a/fs/smb/client/fs_context.c\n+++ b/fs/smb/client/fs_context.c\n@@ -1085,10 +1085,11 @@ static int smb3_reconfigure(struct fs_context *fc)\n \tstruct dentry *root = fc->root;\n \tstruct cifs_sb_info *cifs_sb = CIFS_SB(root->d_sb);\n \tstruct cifs_ses *ses = cifs_sb_master_tcon(cifs_sb)->ses;\n+\tunsigned int old_chan_max;\n \tunsigned int rsize = ctx->rsize, wsize = ctx->wsize;\n \tchar *new_password = NULL, *new_password2 = NULL;\n \tbool need_recon = false;\n-\tint rc;\n+\tint rc, mchan_rc = 0;\n \n \tif (ses->expired_pwd)\n \t\tneed_recon = true;\n@@ -1170,25 +1171,37 @@ static int smb3_reconfigure(struct fs_context *fc)\n \tif ((ctx->multichannel != cifs_sb->ctx->multichannel) ||\n \t    (ctx->max_channels != cifs_sb->ctx->max_channels)) {\n \n-\t\t/* Synchronize ses->chan_max with the new mount context */\n-\t\tsmb3_sync_ses_chan_max(ses, ctx->max_channels);\n-\t\t/* Now update the session's channels to match the new configuration */\n \t\t/* Prevent concurrent scaling operations */\n \t\tspin_lock(&ses->ses_lock);\n \t\tif (ses->flags & CIFS_SES_FLAG_SCALE_CHANNELS) {\n \t\t\tspin_unlock(&ses->ses_lock);\n \t\t\tmutex_unlock(&ses->session_mutex);\n-\t\t\treturn -EINVAL;\n+\t\t\tmchan_rc = -EINVAL;\n+\t\t\tgoto out;\n \t\t}\n \t\tses->flags |= CIFS_SES_FLAG_SCALE_CHANNELS;\n \t\tspin_unlock(&ses->ses_lock);\n \n+\t\told_chan_max = ses->chan_max;\n+\t\t/* Synchronize ses->chan_max with the new mount context */\n+\t\tsmb3_sync_ses_chan_max(ses, ctx->max_channels);\n+\n \t\tmutex_unlock(&ses->session_mutex);\n \n \t\trc = smb3_update_ses_channels(ses, ses->server,\n \t\t\t\t\t       false /* from_reconnect */,\n \t\t\t\t\t       false /* disable_mchan */);\n \n+\t\t/*\n+\t\t * On failure, restore chan_max while still holding\n+\t\t * CIFS_SES_FLAG_SCALE_CHANNELS so a concurrent reconfigure\n+\t\t * cannot observe or race with the rollback.\n+\t\t */\n+\t\tif (rc < 0) {\n+\t\t\tsmb3_sync_ses_chan_max(ses, old_chan_max);\n+\t\t\tmchan_rc = rc;\n+\t\t}\n+\n \t\t/* Clear scaling flag after operation */\n \t\tspin_lock(&ses->ses_lock);\n \t\tses->flags &= ~CIFS_SES_FLAG_SCALE_CHANNELS;\n@@ -1197,6 +1210,7 @@ static int smb3_reconfigure(struct fs_context *fc)\n \t\tmutex_unlock(&ses->session_mutex);\n \t}\n \n+out:\n \tSTEAL_STRING(cifs_sb, ctx, domainname);\n \tSTEAL_STRING(cifs_sb, ctx, nodename);\n \tSTEAL_STRING(cifs_sb, ctx, iocharset);\n@@ -1205,12 +1219,32 @@ static int smb3_reconfigure(struct fs_context *fc)\n \tctx->rsize = rsize ? CIFS_ALIGN_RSIZE(fc, rsize) : cifs_sb->ctx->rsize;\n \tctx->wsize = wsize ? CIFS_ALIGN_WSIZE(fc, wsize) : cifs_sb->ctx->wsize;\n \n+\t/*\n+\t * If the multichannel update failed, restore the old multichannel\n+\t * settings in ctx so smb3_fs_context_dup() does not desync\n+\t * cifs_sb->ctx from ses->chan_max (which was already rolled back).\n+\t */\n+\tif (mchan_rc) {\n+\t\tctx->multichannel = cifs_sb->ctx->multichannel;\n+\t\tctx->max_channels = cifs_sb->ctx->max_channels;\n+\t}\n+\n \tsmb3_cleanup_fs_context_contents(cifs_sb->ctx);\n \trc = smb3_fs_context_dup(cifs_sb->ctx, ctx);\n \tsmb3_update_mnt_flags(cifs_sb);\n+\n+\t/*\n+\t * If smb3_fs_context_dup() failed, cifs_sb->ctx is left in a\n+\t * partially-restored state after the cleanup above. Surface that\n+\t * failure to the caller before any mchan_rc, since it reflects the\n+\t * real recovery status of cifs_sb->ctx rather than the scaling error.\n+\t */\n+\tif (rc)\n+\t\treturn rc;\n+\tif (mchan_rc)\n+\t\treturn mchan_rc;\n #ifdef CONFIG_CIFS_DFS_UPCALL\n-\tif (!rc)\n-\t\trc = dfs_cache_remount_fs(cifs_sb);\n+\trc = dfs_cache_remount_fs(cifs_sb);\n #endif\n \n \treturn rc;\n",
    "prefixes": [
        "v2"
    ]
}