From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 687B4CCA47C for ; Wed, 29 Jun 2022 12:34:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C247D8E0003; Wed, 29 Jun 2022 08:34:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD32D8E0001; Wed, 29 Jun 2022 08:34:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE95C8E0003; Wed, 29 Jun 2022 08:34:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A03638E0001 for ; Wed, 29 Jun 2022 08:34:51 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 5F9FA60734 for ; Wed, 29 Jun 2022 12:34:51 +0000 (UTC) X-FDA: 79631217582.11.71742F5 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf17.hostedemail.com (Postfix) with ESMTP id 45C9840034 for ; Wed, 29 Jun 2022 12:34:50 +0000 (UTC) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4LY16B6BK8zTgCQ; Wed, 29 Jun 2022 20:31:14 +0800 (CST) Received: from dggpemm100009.china.huawei.com (7.185.36.113) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 29 Jun 2022 20:34:45 +0800 Received: from huawei.com (10.175.101.6) by dggpemm100009.china.huawei.com (7.185.36.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 29 Jun 2022 20:34:44 +0800 From: ZhaoLong Wang To: , CC: , , , , , Subject: [PATCH -next,v2] tmpfs: Fix the issue that the mount and remount results are inconsistent. Date: Wed, 29 Jun 2022 20:43:24 +0800 Message-ID: <20220629124324.1640807-1-wangzhaolong1@huawei.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.175.101.6] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm100009.china.huawei.com (7.185.36.113) X-CFilter-Loop: Reflected ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656506090; h=from:from:sender: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: references; bh=YUkgEt0K62ScmzuF42Ys/ZHy08zd+2uIQz6JEvp/FYk=; b=2UicS3abefZJJpJ0QJGKsQFH29BmR9do1vIgptf2woWXPuTMMLaK/wTm3LR+lvY2CgqbrA D1cNl7m9svr5NV6r4b1Hj+7aOwrBcCRMostefcQ/0RjnygDZm9rNbAOp3HLlnQSCxGsd5C Xnu/TBmrdT8bg3GecnGBVN6tiiPUnNM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf17.hostedemail.com: domain of wangzhaolong1@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangzhaolong1@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656506090; a=rsa-sha256; cv=none; b=ZmKky6a8ilSCKGLD/Z8/QaBg6D7/CwbwXBE/2ea6Kf06wgqquTIH6hsHdNHLPpvr7yRFRk bV36aRklYZvcNtOuD0xtdUs54DGy9HyDhN9cwSRbsku3PmoEWw+UomyS8PuLQbHogdBJDR SKyiQQDbGEXda6yUC3SiXD7+WcaRfQE= X-Rspamd-Queue-Id: 45C9840034 Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf17.hostedemail.com: domain of wangzhaolong1@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangzhaolong1@huawei.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 17zmcgdh8ek41zugg3yo84swz1q73e5t X-HE-Tag: 1656506090-884238 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: An undefined-behavior issue has not been completely fixed since commit d14f5efadd84 ("tmpfs: fix undefined-behaviour in shmem_reconfigure()"). In the commit, check in the shmem_reconfigure() is added in remount process to avoid the Ubsan problem. However, the check is not added to the mount process.It cause the inconsistent results between mount and remount. The operations to reproduce the problem in user mode as follow: If nr_blocks is set to 0x8000000000000000, the mounting is successful. # mount tmpfs /dev/shm/ -t tmpfs -o nr_blocks=0x8000000000000000 However, when -o remount is used, the mount fails because of the check in the shmem_reconfigure() # mount tmpfs /dev/shm/ -t tmpfs -o remount,nr_blocks=0x8000000000000000 mount: /dev/shm: mount point not mounted or bad option. Therefore, add checks in the shmem_parse_one() function and remove the check in shmem_reconfigure() to avoid this problem. Signed-off-by: ZhaoLong Wang --- mm/shmem.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/mm/shmem.c b/mm/shmem.c index a6f565308133..b7f2d4a56867 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -3392,7 +3392,7 @@ static int shmem_parse_one(struct fs_context *fc, struct fs_parameter *param) break; case Opt_nr_blocks: ctx->blocks = memparse(param->string, &rest); - if (*rest) + if (*rest || ctx->blocks > S64_MAX) goto bad_value; ctx->seen |= SHMEM_SEEN_BLOCKS; break; @@ -3514,10 +3514,7 @@ static int shmem_reconfigure(struct fs_context *fc) raw_spin_lock(&sbinfo->stat_lock); inodes = sbinfo->max_inodes - sbinfo->free_inodes; - if (ctx->blocks > S64_MAX) { - err = "Number of blocks too large"; - goto out; - } + if ((ctx->seen & SHMEM_SEEN_BLOCKS) && ctx->blocks) { if (!sbinfo->max_blocks) { err = "Cannot retroactively limit size"; -- 2.31.1