From: sashiko-bot@kernel.org
To: "Andrey Albershteyn" <aalbersh@kernel.org>,
ebiggers@kernel.org, hch@lst.de, fsverity@lists.linux.dev
Cc: linux-ext4@vger.kernel.org, dsterba@suse.cz, tytso@mit.edu
Subject: Re: [PATCH 3/5] btrfs: use I_VERITY_BUILDING instead of private flags
Date: Wed, 04 Nov 2026 20:00:52 +0000 [thread overview]
Message-ID: <sashiko-outbox-197985@kernel.org> (raw)
In-Reply-To: <20261104194618.103332-4-aalbersh@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] btrfs: unpropagated btrfs_orphan_add() error in btrfs_begin_enable_verity()
--
commit d32a0bd97250023398879e80e49ecc247da4ccdf
Author: Andrey Albershteyn via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
btrfs: use I_VERITY_BUILDING instead of private flags
This commit removes the BTRFS_INODE_VERITY_IN_PROGRESS inode runtime flag now
that the generic VFS fs-verity path tracks in-progress Merkle tree
construction via I_VERITY_BUILDING.
> diff --git a/fs/btrfs/verity.c b/fs/btrfs/verity.c
> index b34d2247cf84e..82e2ebad0d3e6 100644
> --- a/fs/btrfs/verity.c
> +++ b/fs/btrfs/verity.c
[ ... ]
> @@ -606,8 +600,6 @@ static int btrfs_begin_enable_verity(struct file *filp)
> return PTR_ERR(trans);
>
> ret = btrfs_orphan_add(trans, inode);
> - if (!ret)
> - set_bit(BTRFS_INODE_VERITY_IN_PROGRESS, &inode->runtime_flags);
> btrfs_end_transaction(trans);
>
> return 0;
[Severity: Medium]
In btrfs_begin_enable_verity(), removing the if (!ret) check leaves the return
value of btrfs_orphan_add() in ret unread (which triggers an unused-but-set
variable compiler warning) while the function still ends with return 0.
Previously, if btrfs_orphan_add() failed during the
fsverity_ioctl_enable() -> enable_verity() -> btrfs_begin_enable_verity()
path, BTRFS_INODE_VERITY_IN_PROGRESS was not set. Now, enable_verity() in
fs/verity/enable.c checks the return value of begin_enable_verity():
err = vops->begin_enable_verity(filp);
if (!err) {
spin_lock(&inode->i_lock);
inode_state_set(inode, I_VERITY_BUILDING);
spin_unlock(&inode->i_lock);
}
Because btrfs_begin_enable_verity() returns 0 even when btrfs_orphan_add()
fails and aborts the transaction, enable_verity() will still set
I_VERITY_BUILDING and proceed to build_merkle_tree() without an orphan item.
Should btrfs_begin_enable_verity() return ret instead of 0?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261104194618.103332-1-aalbersh@kernel.org?part=3
next prev parent reply other threads:[~2026-11-04 20:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 19:46 [PATCH 0/5] fsverity: lift ioctl() input masking and runtime inode flag to VFS Andrey Albershteyn
2026-11-04 19:46 ` [f2fs-dev] " Andrey Albershteyn via Linux-f2fs-devel
2026-11-04 19:46 ` [PATCH 1/5] fsverity: strip FS_VERITY_FL from FS_IOC_SETFLAGS Andrey Albershteyn
2026-11-04 19:46 ` [f2fs-dev] " Andrey Albershteyn via Linux-f2fs-devel
2026-11-04 19:55 ` sashiko-bot
2026-11-04 19:46 ` [PATCH 2/5] fsverity: add I_VERITY_BUILDING inode state flag Andrey Albershteyn
2026-11-04 19:46 ` [f2fs-dev] " Andrey Albershteyn via Linux-f2fs-devel
2026-11-04 19:57 ` sashiko-bot
2026-11-04 19:46 ` [PATCH 3/5] btrfs: use I_VERITY_BUILDING instead of private flags Andrey Albershteyn
2026-11-04 19:46 ` [f2fs-dev] " Andrey Albershteyn via Linux-f2fs-devel
2026-11-04 20:00 ` sashiko-bot [this message]
2026-11-04 19:46 ` [PATCH 4/5] ext4: " Andrey Albershteyn
2026-11-04 19:46 ` [f2fs-dev] " Andrey Albershteyn via Linux-f2fs-devel
2026-11-04 20:01 ` sashiko-bot
2026-11-04 19:46 ` [PATCH 5/5] f2fs: " Andrey Albershteyn
2026-11-04 19:46 ` [f2fs-dev] " Andrey Albershteyn via Linux-f2fs-devel
2026-11-04 20:04 ` sashiko-bot
2026-11-05 9:54 ` Andrey Albershteyn
2026-11-04 21:57 ` [PATCH 0/5] fsverity: lift ioctl() input masking and runtime inode flag to VFS Eric Biggers
2026-11-04 21:57 ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
2026-11-05 7:52 ` Christoph Hellwig
2026-11-05 7:52 ` [f2fs-dev] " Christoph Hellwig
2026-11-05 10:56 ` Andrey Albershteyn
2026-11-05 10:56 ` [f2fs-dev] " Andrey Albershteyn via Linux-f2fs-devel
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=sashiko-outbox-197985@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=aalbersh@kernel.org \
--cc=dsterba@suse.cz \
--cc=ebiggers@kernel.org \
--cc=fsverity@lists.linux.dev \
--cc=hch@lst.de \
--cc=linux-ext4@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tytso@mit.edu \
/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.