Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1246552pxb; Fri, 21 Jan 2022 13:16:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJzvVRZ/I0FstuSB57lfZp0zLgKDEXEQS73mcIffQ2Hvf/MWnhqy8Sr3s0XWShUeJd1nJsD3 X-Received: by 2002:a17:90a:5d16:: with SMTP id s22mr2436965pji.81.1642799765050; Fri, 21 Jan 2022 13:16:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642799765; cv=none; d=google.com; s=arc-20160816; b=H2yguLF6szcf3oNYYs/otw9dWOodU7pQeCO50vtEC3PIuoNhDyBzcMRPxsChbfLcuu /WIUHlgvXdnJi4cYgtTja9gpFGvxv3JA3swLNkyixik8UQsjPn2VO6m8Ge8kp0poXc5l 9Y0eWveSXO6fFhlR+dusV5nYVcgYTrWG8TVlXoMyef660ziBPuKUzrGX7pc31SY8QP2Z 6Occe/2db31D+z47WSmP8TQrl5JKzAZzutLHA5Mp5h/eCjumg23vkE/H74DH6S1pZGvm mB23rjp9oqjOyCVQa7tBivFvnhbT9/5ClrrKPgZnx+SSAiFLG8yobNkspPCxom/WBwGf KmiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=gdoMznUoQshM/tm/E+npk4KemjnJfvqDAHaONy/08JA=; b=U3+QcNuCovJiwS+5WMYTlI727XpQljsFneC9pwVGfTAd55fQqJwjyfAub3yMYb77Ep fsjWwI+Sxf0t0jj9pO852hSmgHIFQ3KUe45soXqgF+WDkJnA4rve14UqDjnaP1OQb58K ZBhFb4Nii+s6mE+vcODSx0EH9c7zBPBQJF1BtUEyj5oaSM2cD3aG5HEnA7QJs8cEz0Q9 kLh1PXc0ZwkothOV+WsEJe9J4sBsXqVHXTPoLyAYNjxVaNdWifHmnYob8smh4gsYLYHH /Ze/yN+ZehclIXnY8V///6uBXCcuKbWtxGW+qvXk+g6idDrypv31DzUWaXO+sbEUROrO ACOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BF2bgEEZ; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k22si6719954pls.433.2022.01.21.13.15.51; Fri, 21 Jan 2022 13:16:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BF2bgEEZ; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239392AbiATKUy (ORCPT + 99 others); Thu, 20 Jan 2022 05:20:54 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:20390 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232937AbiATKUx (ORCPT ); Thu, 20 Jan 2022 05:20:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1642674052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=gdoMznUoQshM/tm/E+npk4KemjnJfvqDAHaONy/08JA=; b=BF2bgEEZrvOAoWKbkuJHBFFaR8+kIl4e0ITxD8+jjKyLsfpLtiK3u8frHq6oHfu2Gu8MS5 J3pbBiasvcBHteZUoSMtHYLm7BIZA9QDkx0+He7XtaQsBH+jffVIz9I3Ujxqy3wqEFMQYD zgpmiuiid2eZbjbWPlw1hjH1xIhP2Ls= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-56-v1pGC8SZMyK2CSp7e8szrw-1; Thu, 20 Jan 2022 05:20:51 -0500 X-MC-Unique: v1pGC8SZMyK2CSp7e8szrw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1A89D104FC17; Thu, 20 Jan 2022 10:20:35 +0000 (UTC) Received: from localhost.localdomain (unknown [10.40.194.242]) by smtp.corp.redhat.com (Postfix) with ESMTP id 635CE752B0; Thu, 20 Jan 2022 10:20:34 +0000 (UTC) From: Lukas Czerner To: fstests@vger.kernel.org Cc: linux-ext4@vger.kernel.org Subject: [PATCH] ext4/053: Test remount without changing mount options Date: Thu, 20 Jan 2022 11:20:25 +0100 Message-Id: <20220120102025.42735-1-lczerner@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org With the recent ext4 mount api change we discovered a bugs that weren't caught by this test. It was triggered by remounting the file system either with the same mount options, or without specifying any mount options at all. In this case we would expect the original mount options to remain the same, however this was either not the case, or the remount failed. Add a remount test after a regular mount. Remount once with specifying the original mount option and remount second time without specifying anything. Test the active options after each test. Additionally include all the combinations of data= options in the remount test for the sake of completeness. Signed-off-by: Lukas Czerner --- tests/ext4/053 | 57 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 56 insertions(+), 1 deletion(-) diff --git a/tests/ext4/053 b/tests/ext4/053 index eaa02508..e1e79592 100755 --- a/tests/ext4/053 +++ b/tests/ext4/053 @@ -77,6 +77,10 @@ kernel_gte 5.12 || _notrun "This test is only relevant for kernel versions 5.12 IGNORED="remount,defaults,ignored,removed" CHECK_MINFO="lazytime,noatime,nodiratime,noexec,nosuid,ro" + +# List of options that can't be used for remount even if the argument +# is not changed +CANT_REMOUNT="defaults,remount,abort,journal_path,journal_dev,usrjquota,grpjquota,jqfmt" ERR=0 test_mnt() { @@ -170,6 +174,54 @@ do_mnt() { print_log "(failed mount)" fi + if [ $ret -ne 0 ] || [ -z "$1" ]; then + return $ret + fi + + # Skip options that can't be remounted even if the argument + # is not changed + ( + IFS=',' + for option in $1; do + opt=${option%=*} + if echo $CANT_REMOUNT | grep -w $opt; then + exit 1 + fi + # Skip the remount if we have data=journal on ext3 because + # it will set nodioread_nolock which is not supported on ext3 + # hence remount will fail. Yes it is broken. + if [[ $fstype == "ext3" ]] && [[ $option == "data=journal" ]]; then + exit 1 + fi + done + ) > /dev/null 2>&1 + [ $? -eq 1 ] && return 0 + print_log "(going to remount options $1)" + + # Just remount with original mnt options, don't add anything at all + simple_mount -o remount,$1 $SCRATCH_MNT + ret=$? + if [ $ret -eq 0 ]; then + test_mnt $1 $2 + ret=$? + [ $ret -ne 0 ] && print_log "(not found after remount)" + else + print_log "(failed remount)" + fi + + [ $ret -ne 0 ] && return $ret + + # Plain remount without specifying any mount options + simple_mount -o remount $SCRATCH_MNT + ret=$? + if [ $ret -eq 0 ]; then + test_mnt $1 $2 + ret=$? + [ $ret -ne 0 ] && print_log "(not found after plain remount)" + else + print_log "(failed plain remount)" + fi + return $ret } @@ -556,8 +608,11 @@ for fstype in ext2 ext3 ext4; do if [[ $fstype != "ext2" ]]; then remount noload data=journal norecovery - not_remount data=ordered data=journal + not_remount data=journal data=ordered not_remount data=journal data=writeback + not_remount data=ordered data=journal + not_remount data=ordered data=writeback + not_remount data=writeback data=journal not_remount data=writeback data=ordered fi -- 2.31.1