From patchwork Tue Feb 27 02:00:47 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13573135 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9BAC7EAF1; Tue, 27 Feb 2024 02:00:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999248; cv=none; b=klgXp+z8pwNJgMpN7Pa1qxtq7D24CKcubexWyUnkeb4vKiuVeIGmxpxajGPdYx8oJE6IKQ3jaYsgqIXs1Ih0JR0CeGhPNKXb5/6tbXYjyIyjLE1hE0il84cVC8SGunmD0nY1YzhJJru7huqKM4+4ZF4BKTguGtYQh+rBmFGZSwo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999248; c=relaxed/simple; bh=2owk3JtNox36xuzddMGB20nlVUgICJzv8/Ftvol8Jc8=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CoVDQOQfqLCk85cCXyd6UzaMMxwAuMSi1eLMEbg5sNOTSXAm1kgR76pLXyYGLTBTDgLVf75hP5RjkX1X14e7VARvYCUCYw0eLGHvtRrbQGVyq5WRvDQuxuGbky2+0FHSy3oZQgN4NY3w/PcQWmGJxM6axwQFzHWZT73PzaYjxVM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rJI0Sxw3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rJI0Sxw3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1ED8BC433F1; Tue, 27 Feb 2024 02:00:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708999248; bh=2owk3JtNox36xuzddMGB20nlVUgICJzv8/Ftvol8Jc8=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=rJI0Sxw3cmyf+GYxBpMiHEGpvI8kpzk4277xKSnH1FikA1I4lj6qL1EBazKYXHfOC IeVRZBWihzkk/I0KeBbkHmAr1TNV0+r3ndDZMB7sToOrOlho9PFTcmKH2WmUAnUlRP 0mPzGdZYsCV/m7VBx1JlBWULwzMFRvAcP0VrBVqKt0Y5OMNj2tCKzDIKkt/EDy3BOq SxwlIJuX2eXA24a6iiG26F0izFXD53J1DhAo7cZ6PIO0GUDJTCvThihqf+NF54O9mM EYz7OdnREBXT3+YmVxStufHV+tPljlXGMtEGvgI/mQwdmZj+jpLbc5Jby1o6q7uxFy FPzcoGpgiV9jA== Date: Mon, 26 Feb 2024 18:00:47 -0800 Subject: [PATCH 1/8] generic/604: try to make race occur reliably From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, guan@eryu.me, fstests@vger.kernel.org Message-ID: <170899915233.896550.17140520436176386775.stgit@frogsfrogsfrogs> In-Reply-To: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> References: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong This test will occasionaly fail like so: --- /tmp/fstests/tests/generic/604.out 2024-02-03 12:08:52.349924277 -0800 +++ /var/tmp/fstests/generic/604.out.bad 2024-02-05 04:35:55.020000000 -0800 @@ -1,2 +1,5 @@ QA output created by 604 -Silence is golden +mount: /opt: /dev/sda4 already mounted on /opt. + dmesg(1) may have more information after failed mount system call. +mount -o usrquota,grpquota,prjquota, /dev/sda4 /opt failed +(see /var/tmp/fstests/generic/604.full for details) As far as I can tell, the cause of this seems to be _scratch_mount getting forked and exec'd before the backgrounded umount process has a chance to enter the kernel. When this occurs, the mount() system call will return -EBUSY because this isn't an attempt to make a bind mount. Slow things down slightly by stalling the mount by 10ms. Signed-off-by: Darrick J. Wong --- tests/generic/604 | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tests/generic/604 b/tests/generic/604 index cc6a4b214f..a0dcdcd58e 100755 --- a/tests/generic/604 +++ b/tests/generic/604 @@ -24,10 +24,11 @@ _scratch_mount for i in $(seq 0 500); do $XFS_IO_PROG -f -c "pwrite 0 4K" $SCRATCH_MNT/$i >/dev/null done -# For overlayfs, avoid unmouting the base fs after _scratch_mount -# tries to mount the base fs +# For overlayfs, avoid unmouting the base fs after _scratch_mount tries to +# mount the base fs. Delay the mount attempt by 0.1s in the hope that the +# mount() call will try to lock s_umount /after/ umount has already taken it. $UMOUNT_PROG $SCRATCH_MNT & -_scratch_mount +sleep 0.01s ; _scratch_mount wait echo "Silence is golden" From patchwork Tue Feb 27 02:01:03 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13573136 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64A12748A; Tue, 27 Feb 2024 02:01:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999264; cv=none; b=MWD+G09ZMCU7GB8uARsC/hC3n2uk/URkYag9HFKrlLA4ocjqd9SKgODPDJEOSNM5Guu2WkCONtULjXr8U8L+skpbuHBbOWLNy/tRRhbIyI6HGVIsmkYU0yQsX5xj5/dSKZXezSCFvt4YjJHurJOJ1Sp+rUJoMaQDYkP12PcZbB0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999264; c=relaxed/simple; bh=Qwrrj296wCF8LsYJGMm83wU+JXfefljQJO69a+BbtMs=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=N9DzQ83kcaN4cyHg9wtu9xaZqJzoxgrRmj8X9vbTQ6VB1EAIfdpNw3fNPWzqcLBKDG4Irh4+/mIFeq37BUpOsAs8lyw8+lHE1wzEqvn6d7dR5tOYJY6jUoYKWjhfzgr2tQiAz8/eqcOnNMGBVG7xWBsOfJXy1eaOcLUqgICeFcA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=StPe0xgB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="StPe0xgB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C81DFC433F1; Tue, 27 Feb 2024 02:01:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708999263; bh=Qwrrj296wCF8LsYJGMm83wU+JXfefljQJO69a+BbtMs=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=StPe0xgBgC3w+WRT5XKj3ao96KXWpifZEdvpcf2pzIVr1EOlND+yMncse59SERRyg BgNaUcR7h8piajjZjUx9Z4BOzPeUlaENHJyxjkBrAA9WW+I2b3FSZCsOVb/ebVTHIs QPr8QXGNlfR8g1duHHRMfLKBIr36Uwoe4QkTOyLXfj0uzVqlT5Ir9BsxSKLsBaFtwl eLHZ0e+W2uUJj8FrolaWgdwIis+TFQgHxAkT0fz4IiGkqeirSWlqgUivpWAhmyc+UU t349JDJBs3FWDr+2PNEpOjyy25rVqyUlNW3KZir4QN2MNKoT7U91GQhiCsMc6T5sMh ZyB7VKahKaMZA== Date: Mon, 26 Feb 2024 18:01:03 -0800 Subject: [PATCH 2/8] xfs/155: fail the test if xfs_repair hangs for too long From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, guan@eryu.me, fstests@vger.kernel.org Message-ID: <170899915247.896550.12193016117687961302.stgit@frogsfrogsfrogs> In-Reply-To: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> References: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong There are a few hard to reproduce bugs in xfs_repair where it can deadlock trying to lock a buffer that it already owns. These stalls cause fstests never to finish, which is annoying! To fix this, set up the xfs_repair run to abort after 10 minutes, which will affect the golden output and capture a core file. This doesn't fix xfs_repair, obviously. Signed-off-by: Darrick J. Wong --- tests/xfs/155 | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tests/xfs/155 b/tests/xfs/155 index 302607b510..fba557bff6 100755 --- a/tests/xfs/155 +++ b/tests/xfs/155 @@ -27,6 +27,10 @@ _require_scratch_xfs_crc # needsrepair only exists for v5 _require_populate_commands _require_libxfs_debug_flag LIBXFS_DEBUG_WRITE_CRASH +# Inject a 10 minute abortive timeout on the repair program so that deadlocks +# in the program do not cause fstests to hang indefinitely. +XFS_REPAIR_PROG="timeout -s ABRT 10m $XFS_REPAIR_PROG" + # Populate the filesystem _scratch_populate_cached nofill >> $seqres.full 2>&1 From patchwork Tue Feb 27 02:01:19 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13573137 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01AAA15D0; Tue, 27 Feb 2024 02:01:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999280; cv=none; b=UuMA0hPhOV2mEu1ktdLcMj7lJQ0ZH+u8eZBFagHJwM3803rvUFqUohUESySkCLbA8iyRH6eDXBQaGUtYA40WTg5FDBqrJisgss19bSdBRxgsxIvouBtE96W2CxWXyunyDoC2cOm1D7CKTl4Wx8zIADsF1k2CpZZ8/gIh8fuEo30= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999280; c=relaxed/simple; bh=pY2zO92z0bcQiq4/Quu7kcvBmDBJECejc5jwXkAuh00=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=kH4qkxKPP9qnf0puYYsrlKybItgGhpj+Bb5VGGrwcH/h4rBjW477AGwhru0t6WXh9h2/qvIwkpBmjZRNPjssMzXAiTIeDBEtg8jW0zYL4t9WspAGXdP2ECgnoBWBWk4Wm6CT+DEYyOFHK0X+AeTXbvN6lrJddOLIx97UjMPYG/c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=k4Pvif7z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="k4Pvif7z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81323C433C7; Tue, 27 Feb 2024 02:01:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708999279; bh=pY2zO92z0bcQiq4/Quu7kcvBmDBJECejc5jwXkAuh00=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=k4Pvif7zWwntmmSxr9hel0FcCVknJkySwtTU1LpN/GM/r/nJPRBbA0HDvjaci315g f2o9ARqkN4izoGE98IKIyDOiuPJ5k+26yG/vN93lv80yOpinCQuVPym2uio4n2dsUX w3x60S1knZKPgK5SirXiNFr24KUwJV6ejAWDZ3H1fnYpvUtNjoiYqeShDQNkPFnBws X1LXiLClWbgLnoJXHqEeXFlFXM4P+sMHYMjw7jWZLWopRbE25eQWGA3TC4jBkRHpNL dH01uOh3Co+ckhFdglW1McWp/fR1kB4N46LYfng7dtzlxnr/yVw9qLsgtuTtOyFbGq th1ZZNgacwr3g== Date: Mon, 26 Feb 2024 18:01:19 -0800 Subject: [PATCH 3/8] generic/192: fix spurious timeout From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, guan@eryu.me, fstests@vger.kernel.org Message-ID: <170899915261.896550.17109752514258402651.stgit@frogsfrogsfrogs> In-Reply-To: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> References: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong I have a theory that when the nfs server that hosts the root fs for my testing VMs gets backed up, it can take a while for path resolution and loading of echo, cat, or tee to finish. That delays the test enough to result in: Reviewed-by: Zorro Lang Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- /tmp/fstests/tests/generic/192.out 2023-11-29 15:40:52.715517458 -0800 +++ /var/tmp/fstests/generic/192.out.bad 2023-12-15 21:28:02.860000000 -0800 @@ -1,5 +1,6 @@ QA output created by 192 sleep for 5 seconds test -delta1 is in range +delta1 has value of 12 +delta1 is NOT in range 5 .. 7 delta2 is in range Therefore, invoke all these utilities with --help before the critical section to make sure they're all in memory. Signed-off-by: Darrick J. Wong --- tests/generic/192 | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/tests/generic/192 b/tests/generic/192 index 0d3cd03b4b..2825486635 100755 --- a/tests/generic/192 +++ b/tests/generic/192 @@ -29,17 +29,27 @@ delay=5 testfile=$TEST_DIR/testfile rm -f $testfile +# Preload every binary used between sampling time1 and time2 so that loading +# them has minimal overhead even if the root fs is hosted over a slow network. +# Also don't put pipe and tee creation in that critical section. +for i in echo stat sleep cat; do + $i --help &>/dev/null +done + echo test >$testfile -time1=`_access_time $testfile | tee -a $seqres.full` +time1=`_access_time $testfile` +echo $time1 >> $seqres.full echo "sleep for $delay seconds" sleep $delay # sleep to allow time to move on for access cat $testfile -time2=`_access_time $testfile | tee -a $seqres.full` +time2=`_access_time $testfile` +echo $time2 >> $seqres.full cd / _test_cycle_mount -time3=`_access_time $testfile | tee -a $seqres.full` +time3=`_access_time $testfile` +echo $time3 >> $seqres.full delta1=`expr $time2 - $time1` delta2=`expr $time3 - $time1` From patchwork Tue Feb 27 02:01:34 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13573138 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7DFF4748A; Tue, 27 Feb 2024 02:01:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999295; cv=none; b=oF5dCs3OznTyf7P6kOQvOFs0C0VznqYXM9sNzPUM7FOpL4clz9OmQLrl1y9rpJQqDsxeFSdOfk5RzDAw+s2DE+P3trwhohVSrmXqV0vocdZ77HgXRJfSLpn6oHyElsk+HYgiUIm84QxYNWSGBGVxm6JY01+HK6q/UMfO4hd8CEA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999295; c=relaxed/simple; bh=aphw27qmlWJ4fC882oHpD8RxySiHOtA6AY8L6ilMdCo=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=t5pw49YuHU/bKRAc9A0OfenLuxaw0ooiLGUiML7r/+nkCP0I6b4L+2uTJe4G2UJ2chUSis6pzorejUZtVV8devzlmwiMQZl7dhncj12aUpixZhb9+33NSMKEAo4KSwKv02XWEan9dbmu1C62FT8MTIYj/yNpEuHOAC/jGaHREQM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lAqjeXsF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lAqjeXsF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A751C433F1; Tue, 27 Feb 2024 02:01:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708999295; bh=aphw27qmlWJ4fC882oHpD8RxySiHOtA6AY8L6ilMdCo=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=lAqjeXsFN5x10SpAjKe0Bl7MqDnkX/AOTazuF02VHkLPsbWjbSy5/fl4KTzNKPQ43 w/X4pdGTyJnOf0+iPbAACgn2O849yicNNRUpGDxfHZ5ZYYHFkevpPSGt/73mGzimV9 42TRQ7yRE+dOTSyT7Mt6YeqBbXLoqKKYLlhsY6zpebzQBUjyBLdmJzt17+u+xIdFmU FiuUD+IBRs5rjjLdtY1zHVwE+f1TFAMaK/ILYgUIM2pBoOR9gStCTfKER962d3em2p 7mZCO27GY8mVm7meTDUkzXA1kmHEm8GqyXFNFbm3Xtfz7zv5iSk0p1P3yh0Woi9shI B2WlfTlLjzczg== Date: Mon, 26 Feb 2024 18:01:34 -0800 Subject: [PATCH 4/8] generic/491: increase test timeout From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, guan@eryu.me, fstests@vger.kernel.org Message-ID: <170899915276.896550.7065004814140508980.stgit@frogsfrogsfrogs> In-Reply-To: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> References: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Bump the read timeout in this test to a few seconds just in case it actually takes the IO system more than a second to retrieve the data (e.g. cloud storage network lag). Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang Reviewed-by: Christoph Hellwig --- tests/generic/491 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/generic/491 b/tests/generic/491 index 797b08d506..5a586c122a 100755 --- a/tests/generic/491 +++ b/tests/generic/491 @@ -44,7 +44,7 @@ xfs_freeze -f $SCRATCH_MNT # Read file while filesystem is frozen should succeed # without blocking -$TIMEOUT_PROG -s KILL 1s cat $testfile +$TIMEOUT_PROG -s KILL 5s cat $testfile xfs_freeze -u $SCRATCH_MNT From patchwork Tue Feb 27 02:01:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13573139 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E2EDEEAD7; Tue, 27 Feb 2024 02:01:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999311; cv=none; b=qZ9JAYAIYYwKKA//XT4uXX9p0Kc4fWagUyemvsQTpPVCZnj3SJY5CSjF3GyMa1MNUrkPx61aFqh7ot7Vxh3Wuduv7r7eZY3a8I9FsZ3frYjwxUyHOUuSMHkPhNcWwon5+cAg6T2YpJMorotko2Y71oE+TxqcPkCWBksPL1nQwjg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999311; c=relaxed/simple; bh=dvT9c7kBr+tIQMAf5U4o59zot8fG3gA560mRjYbu2d0=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Aeo7PMGctFvw1/BEZ2U1tigPxBbAW7+6+frEmDftIb9EglMuh/pYhuEMeY3GYv1Q3EBaymE0ZxUz/jCwodbBWjZ9f+vbUgSSJRoPt8IJiWQs67LFq0THKYNXogRCV7Dq8Y1FDSndaj8qr3m8DzK7tipStFEOf+uiYa4xPIwOtqo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GsAiRZcD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GsAiRZcD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3B1CC433C7; Tue, 27 Feb 2024 02:01:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708999310; bh=dvT9c7kBr+tIQMAf5U4o59zot8fG3gA560mRjYbu2d0=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=GsAiRZcDqwUJpxXTU2+jT9hMe3dAsAwWmqBFL5ZbtAk/cIxgxDnWPTqvCAlQW5YKm C8Ooi6wZNGa4lyHUmlcZyom/XJlYtUyyghEpiaqw5AW5L8pyBjq8w7Vxl0Fsv5nVP1 1ZtIRQ1+WGDHfiSiJjeaetvprARoppr8C0iY+zH9U0CVQ7xPBdYcarisMefgyTdkzK 4xg75JeLJWAJMWOi+xEEl96uCFYLKmuavEGPG2ZFOVBpI22Iz6uI0S8sxD9feXJKDb zwsU3GbU70lS+nAPD29mD52sshqtVrcF8mRaG+xM+71FX1qjQ8YarUCW0cqb9ce+vZ mmbI45w83hxng== Date: Mon, 26 Feb 2024 18:01:50 -0800 Subject: [PATCH 5/8] xfs/599: reduce the amount of attrs created here From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: Luis Chamberlain , linux-xfs@vger.kernel.org, guan@eryu.me, fstests@vger.kernel.org Message-ID: <170899915290.896550.10775908547486721272.stgit@frogsfrogsfrogs> In-Reply-To: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> References: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Luis Chamberlain reported insane runtimes in this test: "xfs/599 takes a long time on LBS, but it passes. The amount of time it takes, however, begs the question if the test is could be trimmed to do less work because the larger the block size the larger the number of dirents and xattrs are used to create. The large dirents are not a problem. The amount of time it takes to create xattrs with hashcol however grows exponentially in time. "n=16k takes 5 seconds "n=32k takes 30 seconds "n=64k takes 6-7 minutes "n=1048576 takes 30 hours "n=1048576 is what we use for block size 32k. "Do we really need so many xattrs for larger block sizes for this test?" No, we don't. The goal of this test is to create a two-level dabtree of xattrs having identical hashes. However, the test author (me) apparently forgot that if a dabtree is created in the attr fork, there will be a dabtree entry for each extended attribute, not each attr leaf block. Hence it's a waste of time to multiply da_records_per_block by attr_records_per_block. Reported-by: Luis Chamberlain Fixes: 1cd6b61299 ("xfs: add a couple more tests for ascii-ci problems") Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- tests/xfs/599 | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/tests/xfs/599 b/tests/xfs/599 index b55b62d7f5..57a797f0f5 100755 --- a/tests/xfs/599 +++ b/tests/xfs/599 @@ -43,14 +43,13 @@ longname="$(mktemp --dry-run "$(perl -e 'print "X" x 255;')" | tr ' ' 'X')" echo "creating $nr_dirents dirents from '$longname'" >> $seqres.full _scratch_xfs_db -r -c "hashcoll -n $nr_dirents -p $crash_dir $longname" -# Create enough xattrs to fill two dabtree nodes. Each attribute leaf block -# gets its own record in the dabtree, so we have to create enough attr blocks -# (each full of attrs) to get a dabtree of at least height 2. +# Create enough xattrs to fill two dabtree nodes. Each attribute entry gets +# its own record in the dabtree, so we have to create enough attributes to get +# a dabtree of at least height 2. blksz=$(_get_block_size "$SCRATCH_MNT") -attr_records_per_block=$((blksz / 255)) da_records_per_block=$((blksz / 8)) # 32-bit hash and 32-bit before -nr_attrs=$((da_records_per_block * attr_records_per_block * 2)) +nr_attrs=$((da_records_per_block * 2)) longname="$(mktemp --dry-run "$(perl -e 'print "X" x 249;')" | tr ' ' 'X')" echo "creating $nr_attrs attrs from '$longname'" >> $seqres.full From patchwork Tue Feb 27 02:02:05 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13573140 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A4A04689; Tue, 27 Feb 2024 02:02:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999326; cv=none; b=FXc27T04Ik6TlCz8CUFMtjFBjS/fiC0/7ZOfJEWRlvQVL1/AEwK7Iv7EjTkX7CF02DwpWFJp6ENJ/lmrBZ2n3+WYjZZU73f5O2SV+qiocPrBVcSArabrXK/2KwWDpTBQcgXx9gAEbacBmI/juNQiJC+G1fGhD+acSB34ToNOLy0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999326; c=relaxed/simple; bh=ErRMXqTl92BXMhTv9z7imcrpfDzvCmoTs83req+434M=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cssDL8KN6W31x5Af4AjXOec9BzfESuXh+W21KrcMOWICEncllUlzHL0ypXJGl4+X8lFxsHngO0T2HaRVMpr/kPEdtQmNXl9g9fpgW6z/c25KB921NC1MrmzjfZDqBB6MEIWNZyow/+5sQp9C3wIBTeQD0dVa9UVChWv2Yy3ZIEE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ISczvk7I; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ISczvk7I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E567C433F1; Tue, 27 Feb 2024 02:02:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708999326; bh=ErRMXqTl92BXMhTv9z7imcrpfDzvCmoTs83req+434M=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=ISczvk7IkMecOOVzRkJ9hX0HHTyI8vy1pPVQd2Ox+9hxwnBLnDjpgzvyW1bpLBT0U asu8wG6LZaSO4J3JIFG2wrFpoo/cXR3T2jkipjzBRaKbqy+7cRcEHFHjotjDayvyyl 8oF6u+CeXUWPzE96nKnGEx+NlG2RcC9iZCM3rscvqSBB8apNe4sQGTrTDqNM93Wosz zf+v9YnLe5B9FjtDfyt0vGLPeod7WWPaJjq7CFUd2bbQEnY/9a9h0m1jnmj7JTD33L R7/1JigejLjtxxJIxUBt57Ju/DzdzgtbWjrOrDO94ZK12mso2KznPuG0WVQLelWGLk hJQoJp7s4eQTQ== Date: Mon, 26 Feb 2024 18:02:05 -0800 Subject: [PATCH 6/8] xfs/122: update test to pick up rtword/suminfo ondisk unions From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, guan@eryu.me, fstests@vger.kernel.org Message-ID: <170899915304.896550.17104868811908659798.stgit@frogsfrogsfrogs> In-Reply-To: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> References: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Update this test to check that the ondisk unions for rt bitmap word and rt summary counts are always the correct size. Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- tests/xfs/122 | 2 +- tests/xfs/122.out | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/tests/xfs/122 b/tests/xfs/122 index ba927c77c4..4e5ba1dfee 100755 --- a/tests/xfs/122 +++ b/tests/xfs/122 @@ -195,7 +195,7 @@ echo 'int main(int argc, char *argv[]) {' >>$cprog # cat /usr/include/xfs/xfs*.h | indent |\ _attribute_filter |\ -grep -E '(} *xfs_.*_t|^struct xfs_[a-z0-9_]*$)' |\ +grep -E '(} *xfs_.*_t|^(union|struct) xfs_[a-z0-9_]*$)' |\ grep -E -v -f $tmp.ignore |\ sed -e 's/^.*}[[:space:]]*//g' -e 's/;.*$//g' -e 's/_t, /_t\n/g' |\ sort | uniq |\ diff --git a/tests/xfs/122.out b/tests/xfs/122.out index 067a0ec76b..a2b57cfb9b 100644 --- a/tests/xfs/122.out +++ b/tests/xfs/122.out @@ -124,6 +124,8 @@ sizeof(struct xfs_swap_extent) = 64 sizeof(struct xfs_sxd_log_format) = 16 sizeof(struct xfs_sxi_log_format) = 80 sizeof(struct xfs_unmount_log_format) = 8 +sizeof(union xfs_rtword_raw) = 4 +sizeof(union xfs_suminfo_raw) = 4 sizeof(xfs_agf_t) = 224 sizeof(xfs_agfl_t) = 36 sizeof(xfs_agi_t) = 344 From patchwork Tue Feb 27 02:02:21 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13573141 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 42553EADA; Tue, 27 Feb 2024 02:02:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999342; cv=none; b=QPVqWQa1OnH2bpsuKn6iVs9eZobJnbLxqNO44Nid4apSpcF7zwA0DAgbubwV4sB/iNqxLDp1kKFXjJOjO1cSnpcVTno0WNqtnrCUt3zOfDP5UPw4ERsQbYlR1TP+PD4316CrU+O5tSZd1TmaL/7tWdkgTmKiJZkFe2IZrXCi98A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999342; c=relaxed/simple; bh=5ub7AK73P5Ue1mzO8TMOkE4E25QR0etZcGPjTBCGYy8=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=B2i3+otRofDksJZXlqe0skyWo5xUW9q8B81jV3Xajk4ThgiJRpL9SQT9X7nzVRbL7jHg3+n0630Ludb2mAbfdT4E2w8EsXFzYUGSgqQ78UsTi/F+rO8jL+f9wUCPA3pyOZuD/IyuCLaiXmuRjpOcZGFa9AyHhZzSrOFtxrWjykI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kjQozXrF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kjQozXrF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CFE33C433C7; Tue, 27 Feb 2024 02:02:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708999341; bh=5ub7AK73P5Ue1mzO8TMOkE4E25QR0etZcGPjTBCGYy8=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=kjQozXrFlrpZH0olNG8yyBraP6r3yPY5L630/ieaLJuxWgEldFcyw3YxRNGuBfPDH BVA9M6zL5QWykKF/M0hYtw00LDsAl7lbgDaV12r6tj+j2SnCPLD8bkhvXYY+OJOqL+ MqwmgsSc1lc9/YSojeAN5YdB8GIcm/Rlo+26v4RB+h3mZRX7qxc1ELLCUfL52ifL/U Rg3Tu5LIZr9klj2wiV5B0yEDjx9CUUhP829hwDcpwH08WuQbX5wETnrMujDcofl51n vribeHwUXk+IGCbw3r7kXrC87Lf+H1MyvpwdXu9kMY1K3YQ4UFziCGlMrKD+vipvf0 RQMi82SBhxc0w== Date: Mon, 26 Feb 2024 18:02:21 -0800 Subject: [PATCH 7/8] xfs/43[4-6]: make module reloading optional From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, guan@eryu.me, fstests@vger.kernel.org Message-ID: <170899915319.896550.14222768162023866668.stgit@frogsfrogsfrogs> In-Reply-To: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> References: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong These three tests examine two things -- first, can xfs CoW staging extent recovery handle corruptions in the refcount btree gracefully; and second, can we avoid leaking incore inodes and dquots. The only cheap way to check the second condition is to rmmod and modprobe the XFS module, which triggers leak detection when rmmod tears down the caches. Currently, the entire test is _notrun if module reloading doesn't work. Unfortunately, these tests never run for the majority of XFS developers because their testbeds either compile the xfs kernel driver into vmlinux statically or the rootfs is xfs so the module cannot be reloaded. The author's testbed boots from NFS and does not have this limitation. Because we've had repeated instances of CoW recovery regressions not being caught by testing until for-next hits my machine, let's make the module reloading optional in all three tests to improve coverage. Signed-off-by: Darrick J. Wong --- common/module | 34 +++++++++++++++++++++++++++++----- tests/xfs/434 | 3 +-- tests/xfs/435 | 3 +-- tests/xfs/436 | 3 +-- 4 files changed, 32 insertions(+), 11 deletions(-) diff --git a/common/module b/common/module index 6efab71d34..f6814be34e 100644 --- a/common/module +++ b/common/module @@ -48,12 +48,15 @@ _require_loadable_module() modprobe "${module}" || _notrun "${module} load failed" } -# Check that the module for FSTYP can be loaded. -_require_loadable_fs_module() +# Test if the module for FSTYP can be unloaded and reloaded. +# +# If not, returns 1 if $FSTYP is not a loadable module; 2 if the module could +# not be unloaded; or 3 if loading the module fails. +_test_loadable_fs_module() { local module="$1" - modinfo "${module}" > /dev/null 2>&1 || _notrun "${module}: must be a module." + modinfo "${module}" > /dev/null 2>&1 || return 1 # Unload test fs, try to reload module, remount local had_testfs="" @@ -68,8 +71,29 @@ _require_loadable_fs_module() modprobe "${module}" || load_ok=0 test -n "${had_scratchfs}" && _scratch_mount 2> /dev/null test -n "${had_testfs}" && _test_mount 2> /dev/null - test -z "${unload_ok}" || _notrun "Require module ${module} to be unloadable" - test -z "${load_ok}" || _notrun "${module} load failed" + test -z "${unload_ok}" || return 2 + test -z "${load_ok}" || return 3 + return 0 +} + +_require_loadable_fs_module() +{ + local module="$1" + + _test_loadable_fs_module "${module}" + ret=$? + case "$ret" in + 1) + _notrun "${module}: must be a module." + ;; + 2) + _notrun "${module}: module could not be unloaded" + ;; + 3) + _notrun "${module}: module reload failed" + ;; + esac + return "${ret}" } # Print the value of a filesystem module parameter diff --git a/tests/xfs/434 b/tests/xfs/434 index 12d1a0c9da..ca80e12753 100755 --- a/tests/xfs/434 +++ b/tests/xfs/434 @@ -30,7 +30,6 @@ _begin_fstest auto quick clone fsr # real QA test starts here _supported_fs xfs -_require_loadable_fs_module "xfs" _require_quota _require_scratch_reflink _require_cp_reflink @@ -77,7 +76,7 @@ _scratch_unmount 2> /dev/null rm -f ${RESULT_DIR}/require_scratch echo "See if we leak" -_reload_fs_module "xfs" +_test_loadable_fs_module "xfs" # success, all done status=0 diff --git a/tests/xfs/435 b/tests/xfs/435 index 44135c7653..b52e9287df 100755 --- a/tests/xfs/435 +++ b/tests/xfs/435 @@ -24,7 +24,6 @@ _begin_fstest auto quick clone # real QA test starts here _supported_fs xfs -_require_loadable_fs_module "xfs" _require_quota _require_scratch_reflink _require_cp_reflink @@ -55,7 +54,7 @@ _scratch_unmount 2> /dev/null rm -f ${RESULT_DIR}/require_scratch echo "See if we leak" -_reload_fs_module "xfs" +_test_loadable_fs_module "xfs" # success, all done status=0 diff --git a/tests/xfs/436 b/tests/xfs/436 index d010362785..02bcd66900 100755 --- a/tests/xfs/436 +++ b/tests/xfs/436 @@ -27,7 +27,6 @@ _begin_fstest auto quick clone fsr # real QA test starts here _supported_fs xfs -_require_loadable_fs_module "xfs" _require_scratch_reflink _require_cp_reflink _require_xfs_io_command falloc # fsr requires support for preallocation @@ -72,7 +71,7 @@ _scratch_unmount 2> /dev/null rm -f ${RESULT_DIR}/require_scratch echo "See if we leak" -_reload_fs_module "xfs" +_test_loadable_fs_module "xfs" # success, all done status=0 From patchwork Tue Feb 27 02:02:37 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13573142 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 028594C9B; Tue, 27 Feb 2024 02:02:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999358; cv=none; b=QywyojvkdiuiVExdA6/qPrZLEn9h5WCXsCVy4+MMjnEnCvbZcfUpzt0n9l5hDNaWrA809nt+qldyjDJbc0DX6ZfgPpDB8PXADDVSZJR1ch+EBvPKhZDIIVvF8Xt8iTcAe/p10pD+noQnqKkfbrHLRB6XbZ0USoOQtYMByoBZJuo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708999358; c=relaxed/simple; bh=FKGvam17ZCy+PtLvxrdG7HGDzS8vHZEQkD2Rklyav4g=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=BMPXfcGQLCcUPEwqYeKdofqBDMtAHKzlbNLVxa6CEot0YlnOZJJWPoI0dDCY4Oku6fTM7xQBy7YKXs2REbeDQLZgjAxMpDFg+ctwoFv82MyOeOZiz4dgd5oLz0q7JJsFJpnm14050FHVZbuf+X5vEjscWqmwXZAKJF0KmSago1A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Vb+ka4Mi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Vb+ka4Mi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F22BC433C7; Tue, 27 Feb 2024 02:02:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708999357; bh=FKGvam17ZCy+PtLvxrdG7HGDzS8vHZEQkD2Rklyav4g=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=Vb+ka4MiInLuradAYO6f0xV0YO2FSolyIumE+Iwt/T37pyvBkvZjQQXsbMDyn6z/r R2iMyscroaCod0kVbJVmdnV4rZCqfXgBZi1wlD0RHpiMew1USFr0GZpw13fTCAuLY+ U2Y4bi2pIrnenk/eS95Sie6Oj3NrdNJXf2mCCqonINLFUGKbZ2Mem4udYfP65Wz3D1 yz/MsAJD71zfuKlmNPBfMeZjwThmOiipiT3X0G9ugsPn2cXADa0Q/ES4rpVhQWTu+Y pbcjh2yUAE+fJT0h9PalvH6HF6x+QzH7fuvMGDS8YXwOQ82YnliA9ea+JRM196V6sR 4PKdMG85vGb6g== Date: Mon, 26 Feb 2024 18:02:37 -0800 Subject: [PATCH 8/8] xfs: test for premature ENOSPC with large cow delalloc extents From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, guan@eryu.me, fstests@vger.kernel.org Message-ID: <170899915333.896550.18395785595853879309.stgit@frogsfrogsfrogs> In-Reply-To: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> References: <170899915207.896550.7285890351450610430.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong On a higly fragmented filesystem a Direct IO write can fail with -ENOSPC error even though the filesystem has sufficient number of free blocks. This occurs if the file offset range on which the write operation is being performed has a delalloc extent in the cow fork and this delalloc extent begins much before the Direct IO range. In such a scenario, xfs_reflink_allocate_cow() invokes xfs_bmapi_write() to allocate the blocks mapped by the delalloc extent. The extent thus allocated may not cover the beginning of file offset range on which the Direct IO write was issued. Hence xfs_reflink_allocate_cow() ends up returning -ENOSPC. This test addresses this issue. Signed-off-by: Darrick J. Wong --- common/rc | 14 +++++++++ tests/xfs/1923 | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/xfs/1923.out | 8 +++++ 3 files changed, 107 insertions(+) create mode 100755 tests/xfs/1923 create mode 100644 tests/xfs/1923.out diff --git a/common/rc b/common/rc index 30c44dddd9..d3a2a0718b 100644 --- a/common/rc +++ b/common/rc @@ -1873,6 +1873,20 @@ _require_scratch_delalloc() _scratch_unmount } +# Require test fs supports delay allocation. +_require_test_delalloc() +{ + _require_command "$FILEFRAG_PROG" filefrag + + rm -f $TEST_DIR/testy + $XFS_IO_PROG -f -c 'pwrite 0 64k' $TEST_DIR/testy &> /dev/null + $FILEFRAG_PROG -v $TEST_DIR/testy 2>&1 | grep -q delalloc + res=$? + rm -f $TEST_DIR/testy + test $res -eq 0 || \ + _notrun "test requires delayed allocation buffered writes" +} + # this test needs a test partition - check we're ok & mount it # _require_test() diff --git a/tests/xfs/1923 b/tests/xfs/1923 new file mode 100755 index 0000000000..4e494ad8c2 --- /dev/null +++ b/tests/xfs/1923 @@ -0,0 +1,85 @@ +#! /bin/bash +# SPDX-License-Identifier: GPL-2.0 +# Copyright (c) 2022-2024 Oracle. All Rights Reserved. +# +# FS QA Test No. 1923 +# +# This is a regression test for "xfs: Fix false ENOSPC when performing direct +# write on a delalloc extent in cow fork". If there is a lot of free space but +# it is very fragmented, it's possible that a very large delalloc reservation +# could be created in the CoW fork by a buffered write. If a directio write +# tries to convert the delalloc reservation to a real extent, it's possible +# that the allocation will succeed but fail to convert even the first block of +# the directio write range. In this case, XFS will return ENOSPC even though +# all it needed to do was to keep converting until the allocator returns ENOSPC +# or the first block of the direct write got some space. +# +. ./common/preamble +_begin_fstest auto quick clone + +_cleanup() +{ + cd / + rm -f $file1 $file2 $fragmentedfile +} + +# Import common functions. +. ./common/reflink +. ./common/inject + +# real QA test starts here +_fixed_by_kernel_commit XXXXX \ + "xfs: Fix false ENOSPC when performing direct write on a delalloc extent in cow fork" + +# Modify as appropriate. +_supported_fs generic +_require_test_program "punch-alternating" +_require_test_reflink +_require_xfs_io_error_injection "bmap_alloc_minlen_extent" +_require_test_delalloc + +file1=$TEST_DIR/file1.$seq +file2=$TEST_DIR/file2.$seq +fragmentedfile=$TEST_DIR/fragmentedfile.$seq + +# COW operates on pages, so we must not perform operations in units smaller +# than a page. +blksz=$(_get_file_block_size $TEST_DIR) +pagesz=$(_get_page_size) +if (( $blksz < $pagesz )); then + blksz=$pagesz +fi + +echo "Create source file" +$XFS_IO_PROG -f -c "pwrite 0 $((blksz * 256))" $file1 >> $seqres.full + +sync + +echo "Create Reflinked file" +_cp_reflink $file1 $file2 >> $seqres.full +#$XFS_IO_PROG -f -c "reflink $file1" $file2 >> $seqres.full + +echo "Set cowextsize" +$XFS_IO_PROG -c "cowextsize $((blksz * 128))" -c stat $file1 >> $seqres.full + +echo "Fragment FS" +$XFS_IO_PROG -f -c "pwrite 0 $((blksz * 512))" $fragmentedfile >> $seqres.full +sync +$here/src/punch-alternating $fragmentedfile + +echo "Allocate block sized extent from now onwards" +_test_inject_error bmap_alloc_minlen_extent 1 + +echo "Create big delalloc extent in CoW fork" +$XFS_IO_PROG -c "pwrite 0 $blksz" $file1 >> $seqres.full + +sync + +$XFS_IO_PROG -c 'bmap -elpv' -c 'bmap -celpv' $file1 >> $seqres.full + +echo "Direct I/O write at offset 3FSB" +$XFS_IO_PROG -d -c "pwrite $((blksz * 3)) $((blksz * 2))" $file1 >> $seqres.full + +# success, all done +status=0 +exit diff --git a/tests/xfs/1923.out b/tests/xfs/1923.out new file mode 100644 index 0000000000..a0553cf3ee --- /dev/null +++ b/tests/xfs/1923.out @@ -0,0 +1,8 @@ +QA output created by 1923 +Create source file +Create Reflinked file +Set cowextsize +Fragment FS +Allocate block sized extent from now onwards +Create big delalloc extent in CoW fork +Direct I/O write at offset 3FSB