[Bug 217159] New: WARN in ext4_handle_inode_extension: i_size_read(inode) < EXT4_I(inode)->i_disksize

[Bug 217159] New: WARN in ext4_handle_inode_extension: i_size_read(inode) < EXT4_I(inode)->i_disksize

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217159

            Bug ID: 217159
           Summary: WARN in ext4_handle_inode_extension:
                    i_size_read(inode) < EXT4_I(inode)->i_disksize
           Product: File System
           Version: 2.5
    Kernel Version: 6.3.0-rc1
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
          Assignee: fs_ext4@kernel-bugs.osdl.org
          Reporter: chengzhihao1@huawei.com
        Regression: No

CONFIG_EXT4_FS=y

1. download corrupted ext4 image disk(nonzero i_size for EXT4_BOOT_LOADER_INO)
2. gcc -o bb b.c
3. ./bb
[   16.966779] ------------[ cut here ]------------
[   16.967594] WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319
ext4_file_write_iter+0xbc7/0xd10
[   16.968996] Modules linked in:
[   16.969521] CPU: 0 PID: 2580 Comm: bb Not tainted
6.3.0-rc1-00004-g703695902cfa #1109
[   16.970806] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraprojec4
[   16.973047] RIP: 0010:ext4_file_write_iter+0xbc7/0xd10
[   16.973813] Code: 56 0f e5 0c 01 48 83 05 76 12 e5 0c 01 e9 f1 fd ff ff 48
83 05 a9 14 e5 0c 01 49 89 c7 e9 01 fb ff ff 48 83c
[   16.975571] RSP: 0018:ffffc9000189fde0 EFLAGS: 00010202
[   16.976073] RAX: 0000000000006464 RBX: 0000000000000000 RCX:
00000000038b8000
[   16.976753] RDX: 00000000038b6000 RSI: ffff8881738c60f0 RDI:
0000000000030f70
[   16.977444] RBP: ffffc9000189fe70 R08: ffff8881738c60b8 R09:
ffff8881738c60b8
[   16.978130] R10: 0000000000000307 R11: 0000000000000400 R12:
ffff88817a9c61a0
[   16.978796] R13: 000000000000000a R14: ffffc9000189fe98 R15:
0000000000000400
[   16.979483] FS:  00007f3de0f00440(0000) GS:ffff88842fc00000(0000)
knlGS:0000000000000000
[   16.980251] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   16.980787] CR2: 00007f3de08ffe70 CR3: 000000017576a000 CR4:
00000000000006f0
[   16.981491] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[   16.982179] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[   16.982851] Call Trace:
[   16.983110]  <TASK>
[   16.983327]  ? __ext4_ioctl+0x1375/0x2700
[   16.983711]  vfs_write+0x3b1/0x5c0
[   16.984059]  ksys_write+0x77/0x160
[   16.984395]  __x64_sys_write+0x22/0x30
[   16.984754]  do_syscall_64+0x39/0x80
[   16.985120]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[   16.985611] RIP: 0033:0x7f3de0900130
[   16.985972] Code: 73 01 c3 48 8b 0d 58 ed 2c 00 f7 d8 64 89 01 48 83 c8 ff
c3 66 0f 1f 44 00 00 83 3d b9 45 2d 00 00 75 10 b84
[   16.987744] RSP: 002b:00007ffe63ff5e98 EFLAGS: 00000246 ORIG_RAX:
0000000000000001
[   16.988482] RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
00007f3de0900130
[   16.989181] RDX: 0000000000000400 RSI: 00000000012e1400 RDI:
0000000000000003
[   16.989874] RBP: 00007ffe63ff5eb0 R08: 0000000000000000 R09:
0000000000000450
[   16.990569] R10: 0000000000000003 R11: 0000000000000246 R12:
0000000000400570
[   16.991266] R13: 00007ffe63ff5f90 R14: 0000000000000000 R15:
0000000000000000
[   16.991948]  </TASK>
[   16.992174] ---[ end trace 0000000000000000 ]---

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 217159] WARN in ext4_handle_inode_extension: i_size_read(inode) < EXT4_I(inode)->i_disksize

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217159

--- Comment #1 from Zhihao Cheng (chengzhihao1@huawei.com) ---
Created attachment 303897
  --> https://bugzilla.kernel.org/attachment.cgi?id=303897&action=edit
disk

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 217159] WARN in ext4_handle_inode_extension: i_size_read(inode) < EXT4_I(inode)->i_disksize

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217159

--- Comment #2 from Zhihao Cheng (chengzhihao1@huawei.com) ---
Created attachment 303898
  --> https://bugzilla.kernel.org/attachment.cgi?id=303898&action=edit
b.c

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] ext4: swap i_disksize when swaping the boot loader inode

[Theodore Ts'o]

The following patch fixes the reported issue.

From f4e156cef119f3ffcc56874da4fb9299cc14f68e Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Tue, 7 Mar 2023 23:06:59 -0500
Subject: [PATCH] ext4: swap i_disksize when swaping the boot loader inode

Normally well-behaved of EXT4_IOC_SWAP_BOOT won't actually try to
write to the either inode after using the ioctl, but if they do, the
fact that we're not swapping ei->i_disksize as well as inode->i_size
can trigger warnings.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
---
 fs/ext4/ioctl.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index 2e8c34036313..e552c5db0c95 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -329,9 +329,13 @@ static void swap_inode_data(struct inode *inode1, struct inode *inode2)
 	ext4_es_remove_extent(inode1, 0, EXT_MAX_BLOCKS);
 	ext4_es_remove_extent(inode2, 0, EXT_MAX_BLOCKS);
 
-	isize = i_size_read(inode1);
-	i_size_write(inode1, i_size_read(inode2));
-	i_size_write(inode2, isize);
+	/*
+	 * Both inodes are locked, so we don't need to fool around
+	 * with i_size_read() and i_size_write().
+	 */
+	isize = inode1->i_size;
+	inode1->i_size = ei1->i_disksize = inode2->i_size;
+	inode2->i_size = ei2->i_disksize = isize;
 }
 
 void ext4_reset_inode_seed(struct inode *inode)
-- 
2.31.0

Re: [PATCH] ext4: swap i_disksize when swaping the boot loader inode

[Zhihao Cheng]

Hi Ted,

> The following patch fixes the reported issue.
> 
>>From f4e156cef119f3ffcc56874da4fb9299cc14f68e Mon Sep 17 00:00:00 2001
> From: Theodore Ts'o <tytso@mit.edu>
> Date: Tue, 7 Mar 2023 23:06:59 -0500
> Subject: [PATCH] ext4: swap i_disksize when swaping the boot loader inode
> 
> Normally well-behaved of EXT4_IOC_SWAP_BOOT won't actually try to
> write to the either inode after using the ioctl, but if they do, the
> fact that we're not swapping ei->i_disksize as well as inode->i_size
> can trigger warnings.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> ---
>   fs/ext4/ioctl.c | 10 +++++++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 2e8c34036313..e552c5db0c95 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -329,9 +329,13 @@ static void swap_inode_data(struct inode *inode1, struct inode *inode2)

Shall we drop the redundant assignments 'swap(ei1->i_disksize, 
ei2->i_disksize);' ?

>   	ext4_es_remove_extent(inode1, 0, EXT_MAX_BLOCKS);
>   	ext4_es_remove_extent(inode2, 0, EXT_MAX_BLOCKS);
>   
> -	isize = i_size_read(inode1);
> -	i_size_write(inode1, i_size_read(inode2));
> -	i_size_write(inode2, isize);
> +	/*
> +	 * Both inodes are locked, so we don't need to fool around
> +	 * with i_size_read() and i_size_write().
> +	 */
> +	isize = inode1->i_size;
> +	inode1->i_size = ei1->i_disksize = inode2->i_size;
> +	inode2->i_size = ei2->i_disksize = isize;
>   }
>   
>   void ext4_reset_inode_seed(struct inode *inode)
> 

[Bug 217159] WARN in ext4_handle_inode_extension: i_size_read(inode) < EXT4_I(inode)->i_disksize

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217159

Theodore Tso (tytso@mit.edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@mit.edu

--- Comment #3 from Theodore Tso (tytso@mit.edu) ---
I guess if you edit the subject line, bugzilla won't be able to thread the
reply.   It could use the in-reply-to header, but apparently.... it doesn't.

Reply and fix here:
https://lore.kernel.org/all/20230308041252.GC860405@mit.edu/

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.