[PATCH] btrfs: remove assertions after btrfs_bio struct changes

[PATCH] btrfs: remove assertions after btrfs_bio struct changes

[Zhen Ni]

Commit 81cea6cd7041 ("btrfs: remove btrfs_bio::fs_info by extracting it
from btrfs_bio::inode") modified the btrfs_bio structure to make the
inode field mandatory, making these assertions redundant:

- btrfs_check_read_bio(): inode is validated by btrfs_bio_init()
- btrfs_submit_bbio(): condition always passes since inode is never NULL

Remove these obsolete checks.

Signed-off-by: Zhen Ni <zhen.ni@easystack.cn>
---
 fs/btrfs/bio.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/fs/btrfs/bio.c b/fs/btrfs/bio.c
index fa1d321a2fb8..2b6a97fba1b2 100644
--- a/fs/btrfs/bio.c
+++ b/fs/btrfs/bio.c
@@ -307,9 +307,6 @@ static void btrfs_check_read_bio(struct btrfs_bio *bbio, struct btrfs_device *de
 	phys_addr_t paddr;
 	u32 offset = 0;
 
-	/* Read-repair requires the inode field to be set by the submitter. */
-	ASSERT(inode);
-
 	/*
 	 * Hand off repair bios to the repair code as there is no upper level
 	 * submitter for them.
@@ -899,9 +896,6 @@ static void assert_bbio_alignment(struct btrfs_bio *bbio)
 
 void btrfs_submit_bbio(struct btrfs_bio *bbio, int mirror_num)
 {
-	/* If bbio->inode is not populated, its file_offset must be 0. */
-	ASSERT(bbio->inode || bbio->file_offset == 0);
-
 	assert_bbio_alignment(bbio);
 
 	while (!btrfs_submit_chunk(bbio, mirror_num))
-- 
2.20.1

Re: [PATCH] btrfs: remove assertions after btrfs_bio struct changes

[David Sterba]

On Thu, Dec 18, 2025 at 08:22:15PM +0800, Zhen Ni wrote:
> Commit 81cea6cd7041 ("btrfs: remove btrfs_bio::fs_info by extracting it
> from btrfs_bio::inode") modified the btrfs_bio structure to make the
> inode field mandatory, making these assertions redundant:
> 
> - btrfs_check_read_bio(): inode is validated by btrfs_bio_init()
> - btrfs_submit_bbio(): condition always passes since inode is never NULL
> 
> Remove these obsolete checks.

The assertions may be redundant and their purpose is to catch accidental
changes to code or explicitly list some critical assumptions. We'd like
to have more rather than fewer of them.

Re: [PATCH] btrfs: remove assertions after btrfs_bio struct changes

[David Sterba]

On Thu, Dec 18, 2025 at 02:57:25PM +0100, David Sterba wrote:
> On Thu, Dec 18, 2025 at 08:22:15PM +0800, Zhen Ni wrote:
> > Commit 81cea6cd7041 ("btrfs: remove btrfs_bio::fs_info by extracting it
> > from btrfs_bio::inode") modified the btrfs_bio structure to make the
> > inode field mandatory, making these assertions redundant:
> > 
> > - btrfs_check_read_bio(): inode is validated by btrfs_bio_init()
> > - btrfs_submit_bbio(): condition always passes since inode is never NULL
> > 
> > Remove these obsolete checks.
> 
> The assertions may be redundant and their purpose is to catch accidental
> changes to code or explicitly list some critical assumptions. We'd like
> to have more rather than fewer of them.

https://btrfs.readthedocs.io/en/latest/dev/Development-notes.html#handling-unexpected-conditions

Re: [PATCH] btrfs: remove assertions after btrfs_bio struct changes

[zhen.ni]

在 2025/12/18 22:05, David Sterba 写道:
> On Thu, Dec 18, 2025 at 02:57:25PM +0100, David Sterba wrote:
>> On Thu, Dec 18, 2025 at 08:22:15PM +0800, Zhen Ni wrote:
>>> Commit 81cea6cd7041 ("btrfs: remove btrfs_bio::fs_info by extracting it
>>> from btrfs_bio::inode") modified the btrfs_bio structure to make the
>>> inode field mandatory, making these assertions redundant:
>>>
>>> - btrfs_check_read_bio(): inode is validated by btrfs_bio_init()
>>> - btrfs_submit_bbio(): condition always passes since inode is never NULL
>>>
>>> Remove these obsolete checks.
>>
>> The assertions may be redundant and their purpose is to catch accidental
>> changes to code or explicitly list some critical assumptions. We'd like
>> to have more rather than fewer of them.
> 
> https://btrfs.readthedocs.io/en/latest/dev/Development-notes.html#handling-unexpected-conditions
> 
> 

Thank you for pointing out the relevant documentation.

Maintaining these assertions (or even adding more) is the better 
approach. They not only prevent current errors but, more importantly, 
prevent future code modifications from introducing problems.