From: Daniel Linjama <daniel@dev.linjama.com>
To: linux-btrfs@vger.kernel.org
Cc: David Sterba <dsterba@suse.com>, Chris Mason <mason@kernel.org>,
linux-kernel@vger.kernel.org,
Daniel Linjama <daniel@dev.linjama.com>
Subject: [PATCH] btrfs: don't force the filesystem read-only on EDQUOT/ENOSPC verity rollback
Date: Mon, 14 Sep 2026 09:24:59 +0300 [thread overview]
Message-ID: <20260914062459.3889313-1-daniel@dev.linjama.com> (raw)
When enable_verity() hits the qgroup limit, rollback_verity() needs its
own metadata reservation. When the qgroup limit refuses the rollback,
the whole filesystem is forced read-only even though the qgroup limit
was for one subvolume only.
Skip btrfs_handle_fs_error() for -EDQUOT/-ENOSPC and just return the
error. The verity orphan item is left in place but the orphan cleanup
from commit 705242538ff3 ("btrfs: verity metadata orphan items") will
remove it at the next mount. fsverity enable still correctly fails but
the filesystem is not forced read-only.
Fixes: 146054090b08 ("btrfs: initial fsverity support")
Signed-off-by: Daniel Linjama <daniel@dev.linjama.com>
---
Verified on a virtual machine with a mainline kernel (08df884136f1) and
a loop-mounted btrfs, with either a qgroup limit on a subvolume or a
full filesystem. On the unpatched kernel the whole filesystem was forced
read-only. On the patched kernel fsverity enable returns -EDQUOT/-ENOSPC
and the filesystem stays read-write.
fs/btrfs/verity.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/verity.c b/fs/btrfs/verity.c
index 4e0ab5842274..8d0f9eea4c39 100644
--- a/fs/btrfs/verity.c
+++ b/fs/btrfs/verity.c
@@ -441,7 +441,9 @@ static int del_orphan(struct btrfs_trans_handle *trans, struct btrfs_inode *inod
*
* We try to handle recoverable errors while enabling verity by rolling it back
* and just failing the operation, rather than having an fs level error no
- * matter what. However, any error in rollback is unrecoverable.
+ * matter what. Failing to delete the verity items for lack of space is
+ * tolerated, the orphan item ensures they are removed on the next mount.
+ * Any other error in rollback is unrecoverable.
*
* Returns 0 on success, negative error code on failure.
*/
@@ -456,9 +458,21 @@ static int rollback_verity(struct btrfs_inode *inode)
clear_bit(BTRFS_INODE_VERITY_IN_PROGRESS, &inode->runtime_flags);
ret = btrfs_drop_verity_items(inode);
if (ret) {
- btrfs_handle_fs_error(root->fs_info, ret,
- "failed to drop verity items in rollback %llu",
- inode->vfs_inode.i_ino);
+ /*
+ * -EDQUOT and -ENOSPC mean we could not reserve metadata to
+ * delete the verity items. That is not a consistency problem,
+ * so don't turn the filesystem read-only. Leave the items and
+ * the orphan in place, orphan cleanup on the next mount will
+ * remove them.
+ */
+ if (ret != -EDQUOT && ret != -ENOSPC)
+ btrfs_handle_fs_error(root->fs_info, ret,
+ "failed to drop verity items in rollback %llu",
+ inode->vfs_inode.i_ino);
+ else
+ btrfs_warn(root->fs_info,
+ "failed to drop verity items in rollback %llu: %pe",
+ inode->vfs_inode.i_ino, ERR_PTR(ret));
goto out;
}
--
2.55.0
next reply other threads:[~2026-09-14 6:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 6:24 Daniel Linjama [this message]
2026-09-14 6:32 ` [PATCH] btrfs: don't force the filesystem read-only on EDQUOT/ENOSPC verity rollback Qu Wenruo
2026-09-14 9:15 ` Qu Wenruo
2026-09-15 6:07 ` Daniel Linjama
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260914062459.3889313-1-daniel@dev.linjama.com \
--to=daniel@dev.linjama.com \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.