From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C362606A320 for ; Fri, 30 Oct 2026 02:59:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=UWpLp7tJ; dkim=fail reason="signature verification failed" (1024-bit key, unprotected) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.a=rsa-sha256 header.s=default header.b=hSHEsgsY DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=LkQd/cnvp31pIKjm8cWz04s1RPcurEWb5SmqZpgu5g0=; b=UWpLp7tJPOmQ8ZT+wDbb/iR6US Qlg1M8SxMplS3iK4ff2NA9loBcuUQpt8bLuIHUA0WYVllUR4ytiWXkeD38lxXi18wA7TWtLgq5+su aQPuD5tJWc5GTkjXYegGw4Ul8toW5YuQoGwTl0Bd5ytqVkUMc+WaStHKU/MaW+4vREPsrV+qxFV5b MTXcJew0wHDRRhlSU9AFrg4LYMLe+tjbTHRfeVKRaE6SMmZ87cLnjIm1oCoTyWrcL0vLWjQcHgMw4 Ab/2dBwSRyQakEP3LkWCk0eJVIwFM2mGPrvDpvELMyQjyVfR7MWG0WZQHllegJz03ghPnndWS8XIv ZeRMo7iA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xMcpa-0000000AhSx-0lcl; Fri, 30 Oct 2026 02:59:02 +0000 Received: from out30-112.freemail.mail.aliyun.com ([115.124.30.112]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xMcpW-0000000AhST-2AEX for linux-mtd@lists.infradead.org; Fri, 30 Oct 2026 02:59:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1793329134; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=w/Jd2p/prMhPtETNelJfTcFSgzTHlHRnVEoen9y0JaA=; b=hSHEsgsYOl/knZoiaKmOo9/szTsdb243LBtAHNpX/8InfeQ+O8kqyPkUuu0Awv2qPGL1dtHu80lxiinShoX3C//q9xO3uJS7nJ9pA7n/Uvoqx9PjlbXVT4MQjJDtbupw0uuaN9Pd4ZUnz3XFWW920V7V0LBApZUCRivWHHA722Q= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R961e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037026112;MF=joseph.qi@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0XDkufcn_1793329132; Received: from 30.221.129.214(mailfrom:joseph.qi@linux.alibaba.com fp:SMTPD_---0XDkufcn_1793329132 cluster:ay36) by smtp.aliyun-inc.com; Fri, 30 Oct 2026 10:58:53 +0800 Message-ID: <0a8576a4-e397-4a49-ab0e-8f0f32bf2642@linux.alibaba.com> Date: Fri, 30 Oct 2026 10:58:52 +0800 X-Archived-By: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/34] ocfs2: keep the current mount options on remount To: Christian Brauner , linux-fsdevel@vger.kernel.org, Jan Kara Cc: Al Viro , ecryptfs@vger.kernel.org, linux-ext4@vger.kernel.org, jfs-discussion@lists.sourceforge.net, linux-nilfs@vger.kernel.org, exfat@lists.linux.dev, linux-mm@kvack.org, ntfs@lists.linux.dev, ocfs2-devel@lists.linux.dev, linux-btrfs@vger.kernel.org, gfs2@lists.linux.dev, linux-efi@vger.kernel.org, linux-mtd@lists.infradead.org, linux-xfs@vger.kernel.org References: <20261029-work-fs-sb_rdonly-v2-0-2f44f64f0b66@kernel.org> <20261029-work-fs-sb_rdonly-v2-19-2f44f64f0b66@kernel.org> From: Joseph Qi In-Reply-To: <20261029-work-fs-sb_rdonly-v2-19-2f44f64f0b66@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20261029_195859_191070_DC080558 X-CRM114-Status: GOOD ( 18.49 ) X-Spam-Score: -17.6 (-----------------) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 On 10/30/26 12:07 AM, Christian Brauner wrote: > ocfs2_init_fs_context() doesn't inherit the current mount options for a > reconfigure. But ocfs2_check_set_options() insists on exactly one > heartbeat mode and ocfs2_reconfigure() refuses to change the data mode. > So every remount without heartbeat= fails with EINVAL, including > emergency remount (sysrq u) which passes no options at all, and that > WARNs for every ocfs2 mounted read-write. A remount that does pass > heartbeat= silently resets every option it doesn't repeat, e.g. noacl, > errors=, barrier= and preferred_slot=. > > So start a reconfigure from the current options like exfat and gfs2 do. > Asking for a different data or heartbeat mode still fails with EINVAL. > > The next patch stops ocfs2 from setting SB_RDONLY after errors. An > errored ocfs2 then stays read-write and emergency remount would run into > this as well. > > Signed-off-by: Christian Brauner (Amutable) > --- > fs/ocfs2/super.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c > index 0af2245ae303..67283244426e 100644 > --- a/fs/ocfs2/super.c > +++ b/fs/ocfs2/super.c > @@ -1222,6 +1222,19 @@ static int ocfs2_init_fs_context(struct fs_context *fc) > mopt->resv_level = OCFS2_DEFAULT_RESV_LEVEL; > mopt->dir_resv_level = -1; > > + /* > + * Start from the current options so a remount only changes what it > + * specifies, emergency remount passes none at all. > + */ > + if (fc->purpose == FS_CONTEXT_FOR_RECONFIGURE) { > + struct ocfs2_super *osb = OCFS2_SB(fc->root->d_sb); > + > + mopt->mount_opt = osb->s_mount_opt; > + mopt->atime_quantum = osb->s_atime_quantum; > + mopt->slot = osb->preferred_slot; > + mopt->user_stack = ocfs2_userspace_stack(osb); > + } ocfs2_reconfigure() decides the transition from fc->sb_flags alone without sb_flags_mask test, unlike reconfigure_super(). And fspick() passes fs_context_for_reconfigure(target.dentry, 0, 0). So on a read-only mount: fspick(AT_FDCWD, "/mnt", 0) sb_flags 0, sb_flags_mask 0 fsconfig(fd, FSCONFIG_SET_STRING, "atime_quantum", "30", 0) fsconfig(fd, FSCONFIG_CMD_RECONFIGURE) reconfigure_super() ocfs2_reconfigure() (bool)(0 & SB_RDONLY) != sb_rdonly(sb) -> 0 != 1, enters fc->sb_flags & SB_RDONLY -> 0, takes the rw branch sb->s_flags &= ~SB_RDONLY osb->osb_flags &= ~OCFS2_OSB_SOFT_RO ocfs2_enable_quotas(osb) -> writes the quota files The final WRITE_ONCE(sb->s_flags, ...) in reconfigure_super() then leaves it cleared, because SB_RDONLY is not in sb_flags_mask. The same falls out of a legacy remount whose flags omit MS_RDONLY. So it seems we should test sb_flags_mask as well? Thanks, Joseph > + > fc->fs_private = mopt; > fc->ops = &ocfs2_context_ops; > > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/