[syzbot] [ext4?] divide error in ext4_mb_regular_allocator

[syzbot] [ext4?] divide error in ext4_mb_regular_allocator

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    ee9a43b7cfe2 Merge tag 'net-6.11-rc3' of git://git.kernel...
git tree:       upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1655c15d980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=9358cc4a2e37fd30
dashboard link: https://syzkaller.appspot.com/bug?extid=1ad8bac5af24d01e2cbd
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=15a8fbc9980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17bc726d980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/e6062f24de48/disk-ee9a43b7.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/5d3ec6153dbd/vmlinux-ee9a43b7.xz
kernel image: https://storage.googleapis.com/syzbot-assets/98dbabb91d02/bzImage-ee9a43b7.xz
mounted in repro #1: https://storage.googleapis.com/syzbot-assets/4dd4c0acf870/mount_0.gz
mounted in repro #2: https://storage.googleapis.com/syzbot-assets/ca52271baf46/mount_1.gz

The issue was bisected to:

commit 1f6bc02f18489b9c9ea39b068d0695fb0e4567e9
Author: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Date:   Fri Dec 15 11:19:50 2023 +0000

    ext4: fallback to complex scan if aligned scan doesn't work

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=118a3d11980000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=138a3d11980000
console output: https://syzkaller.appspot.com/x/log.txt?x=158a3d11980000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1ad8bac5af24d01e2cbd@syzkaller.appspotmail.com
Fixes: 1f6bc02f1848 ("ext4: fallback to complex scan if aligned scan doesn't work")

EXT4-fs: Ignoring removed oldalloc option
EXT4-fs (loop0): re-mounted 00000000-0000-0000-0000-000000000000 r/w. Quota mode: none.
Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 UID: 0 PID: 5224 Comm: syz-executor196 Not tainted 6.11.0-rc2-syzkaller-00111-gee9a43b7cfe2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
RIP: 0010:ext4_mb_regular_allocator+0x1687/0x3b80 fs/ext4/mballoc.c:2932
Code: 16 00 00 8b 1a bf 40 00 00 00 89 de e8 e2 ab 38 ff 48 83 fb 3f 0f 87 9f 19 00 00 e8 93 a7 38 ff 89 d9 49 d3 ec 4c 89 f8 31 d2 <49> f7 f4 48 89 d3 31 ff 48 89 d6 e8 59 ac 38 ff 83 bc 24 64 01 00
RSP: 0018:ffffc9000341e740 EFLAGS: 00010246
RAX: 0000000000000001 RBX: 0000000000000004 RCX: 0000000000000004
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000040
RBP: ffffc9000341e9f0 R08: ffffffff825acf3e R09: ffffffff825bea62
R10: 0000000000000005 R11: ffff8880282b1e00 R12: 0000000000000000
R13: 0000000000000003 R14: ffff8880663270e0 R15: 0000000000000001
FS:  0000555592670380(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe13f0d000 CR3: 0000000025072000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 ext4_mb_new_blocks+0x10a8/0x4e30 fs/ext4/mballoc.c:6219
 ext4_ext_map_blocks+0x1c74/0x77b0 fs/ext4/extents.c:4318
 ext4_map_blocks+0xa5e/0x1d20 fs/ext4/inode.c:652
 _ext4_get_block+0x239/0x6b0 fs/ext4/inode.c:794
 ext4_get_block_unwritten+0x2f/0x100 fs/ext4/inode.c:827
 __block_write_begin_int+0x50c/0x1a70 fs/buffer.c:2125
 ext4_try_to_write_inline_data+0x7ed/0x1360 fs/ext4/inline.c:739
 ext4_write_begin+0x2a0/0x10e0 fs/ext4/inode.c:1172
 ext4_da_write_begin+0x300/0xa70 fs/ext4/inode.c:2943
 generic_perform_write+0x399/0x840 mm/filemap.c:4019
 ext4_buffered_write_iter+0xc6/0x350 fs/ext4/file.c:299
 ext4_file_write_iter+0x1de/0x1a10
 do_iter_readv_writev+0x60a/0x890
 vfs_writev+0x37c/0xbb0 fs/read_write.c:971
 do_pwritev fs/read_write.c:1072 [inline]
 __do_sys_pwritev2 fs/read_write.c:1131 [inline]
 __se_sys_pwritev2+0x1ca/0x2d0 fs/read_write.c:1122
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb9c91a61d9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe13f0c6c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000148
RAX: ffffffffffffffda RBX: 00007fb9c91ef095 RCX: 00007fb9c91a61d9
RDX: 000000000000000f RSI: 00000000200002c0 RDI: 0000000000000004
RBP: 0031656c69662f2e R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000a12 R11: 0000000000000246 R12: 70756f7267647362
R13: 7461785f72657375 R14: 431bde82d7b634db R15: 00007fb9c91ef03b
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ext4_mb_regular_allocator+0x1687/0x3b80 fs/ext4/mballoc.c:2932
Code: 16 00 00 8b 1a bf 40 00 00 00 89 de e8 e2 ab 38 ff 48 83 fb 3f 0f 87 9f 19 00 00 e8 93 a7 38 ff 89 d9 49 d3 ec 4c 89 f8 31 d2 <49> f7 f4 48 89 d3 31 ff 48 89 d6 e8 59 ac 38 ff 83 bc 24 64 01 00
RSP: 0018:ffffc9000341e740 EFLAGS: 00010246
RAX: 0000000000000001 RBX: 0000000000000004 RCX: 0000000000000004
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000040
RBP: ffffc9000341e9f0 R08: ffffffff825acf3e R09: ffffffff825bea62
R10: 0000000000000005 R11: ffff8880282b1e00 R12: 0000000000000000
R13: 0000000000000003 R14: ffff8880663270e0 R15: 0000000000000001
FS:  0000555592670380(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe13f0d000 CR3: 0000000025072000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess), 1 bytes skipped:
   0:	00 00                	add    %al,(%rax)
   2:	8b 1a                	mov    (%rdx),%ebx
   4:	bf 40 00 00 00       	mov    $0x40,%edi
   9:	89 de                	mov    %ebx,%esi
   b:	e8 e2 ab 38 ff       	call   0xff38abf2
  10:	48 83 fb 3f          	cmp    $0x3f,%rbx
  14:	0f 87 9f 19 00 00    	ja     0x19b9
  1a:	e8 93 a7 38 ff       	call   0xff38a7b2
  1f:	89 d9                	mov    %ebx,%ecx
  21:	49 d3 ec             	shr    %cl,%r12
  24:	4c 89 f8             	mov    %r15,%rax
  27:	31 d2                	xor    %edx,%edx
* 29:	49 f7 f4             	div    %r12 <-- trapping instruction
  2c:	48 89 d3             	mov    %rdx,%rbx
  2f:	31 ff                	xor    %edi,%edi
  31:	48 89 d6             	mov    %rdx,%rsi
  34:	e8 59 ac 38 ff       	call   0xff38ac92
  39:	83                   	.byte 0x83
  3a:	bc 24 64 01 00       	mov    $0x16424,%esp


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [ext4?] divide error in ext4_mb_regular_allocator

[Edward Adam Davis]

Before determining that the goal length is a multiple of the stripe size, 
check CR_GOAL_LEN_FAST and CR_BEST_AVAIL_LEN first.

Fixes: 1f6bc02f1848 ("ext4: fallback to complex scan if aligned scan doesn't work")
Reported-by: syzbot+1ad8bac5af24d01e2cbd@syzkaller.appspotmail.com

#syz test: upstream ee9a43b7cfe2

diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 9dda9cd68ab2..451f92cde461 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2928,13 +2928,12 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
 			if (cr == CR_POWER2_ALIGNED)
 				ext4_mb_simple_scan_group(ac, &e4b);
 			else {
-				bool is_stripe_aligned = sbi->s_stripe &&
+				bool is_stripe_aligned = (cr == CR_GOAL_LEN_FAST ||
+					cr == CR_BEST_AVAIL_LEN) && sbi->s_stripe &&
 					!(ac->ac_g_ex.fe_len %
 					  EXT4_B2C(sbi, sbi->s_stripe));
 
-				if ((cr == CR_GOAL_LEN_FAST ||
-				     cr == CR_BEST_AVAIL_LEN) &&
-				    is_stripe_aligned)
+				if (is_stripe_aligned)
 					ext4_mb_scan_aligned(ac, &e4b);
 
 				if (ac->ac_status == AC_STATUS_CONTINUE)

Re: [syzbot] [ext4?] divide error in ext4_mb_regular_allocator

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+1ad8bac5af24d01e2cbd@syzkaller.appspotmail.com
Tested-by: syzbot+1ad8bac5af24d01e2cbd@syzkaller.appspotmail.com

Tested on:

commit:         ee9a43b7 Merge tag 'net-6.11-rc3' of git://git.kernel...
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=12dedb5d980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=9358cc4a2e37fd30
dashboard link: https://syzkaller.appspot.com/bug?extid=1ad8bac5af24d01e2cbd
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=17fd71ed980000

Note: testing is done by a robot and is best-effort only.

[PATCH] ext4: fix divide error in ext4_mb_regular_allocator

[Edward Adam Davis]

Before determining that the goal length is a multiple of the stripe size,
check CR_GOAL_LEN_FAST and CR_BEST_AVAIL_LEN first.

Fixes: 1f6bc02f1848 ("ext4: fallback to complex scan if aligned scan doesn't work")
Reported-and-tested-by: syzbot+1ad8bac5af24d01e2cbd@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1ad8bac5af24d01e2cbd
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 fs/ext4/mballoc.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 9dda9cd68ab2..451f92cde461 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2928,13 +2928,12 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
 			if (cr == CR_POWER2_ALIGNED)
 				ext4_mb_simple_scan_group(ac, &e4b);
 			else {
-				bool is_stripe_aligned = sbi->s_stripe &&
+				bool is_stripe_aligned = (cr == CR_GOAL_LEN_FAST ||
+					cr == CR_BEST_AVAIL_LEN) && sbi->s_stripe &&
 					!(ac->ac_g_ex.fe_len %
 					  EXT4_B2C(sbi, sbi->s_stripe));
 
-				if ((cr == CR_GOAL_LEN_FAST ||
-				     cr == CR_BEST_AVAIL_LEN) &&
-				    is_stripe_aligned)
+				if (is_stripe_aligned)
 					ext4_mb_scan_aligned(ac, &e4b);
 
 				if (ac->ac_status == AC_STATUS_CONTINUE)
-- 
2.43.0

Re: [PATCH] ext4: fix divide error in ext4_mb_regular_allocator

[Ojaswin Mujoo]

On Wed, Aug 14, 2024 at 10:12:00AM +0800, Edward Adam Davis wrote:
> Before determining that the goal length is a multiple of the stripe size,
> check CR_GOAL_LEN_FAST and CR_BEST_AVAIL_LEN first.
> 
> Fixes: 1f6bc02f1848 ("ext4: fallback to complex scan if aligned scan doesn't work")
> Reported-and-tested-by: syzbot+1ad8bac5af24d01e2cbd@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=1ad8bac5af24d01e2cbd
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>  fs/ext4/mballoc.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 9dda9cd68ab2..451f92cde461 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -2928,13 +2928,12 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
>       if (cr == CR_POWER2_ALIGNED)
>         ext4_mb_simple_scan_group(ac, &e4b);
>       else {
> -       bool is_stripe_aligned = sbi->s_stripe &&
> +       bool is_stripe_aligned = (cr == CR_GOAL_LEN_FAST ||
> +         cr == CR_BEST_AVAIL_LEN) && sbi->s_stripe &&
>           !(ac->ac_g_ex.fe_len %
>             EXT4_B2C(sbi, sbi->s_stripe));

Hi Edward, 

Thanks for the patch. So I didn't get a chance to look at syszcaller
report but assuming that EXT4_B2C(sbi, sbi->s_stripe) is becoming 0,
I'm not understanding how is this patch fixing the bug?

It just seems to short circuit the actual bug but we might still hit it
right? 

As for EXT4_B2C(stripe) becoming zero, I have 2 observations:

1. We should definitely be using EXT4_NUM_B2C() here to make sure we
   don't get 0 if stripe is less than cluster size.

2. That being saidIm not sure if it's even possible for this to become zero
   because we do check that stripe size is a multiple of cluster size in
   ext4_fill_super, else we disable it:

  /*
   * It's hard to get stripe aligned blocks if stripe is not aligned with
   * cluster, just disable stripe and alert user to simpfy code and avoid
   * stripe aligned allocation which will rarely successes.
   */
  if (sbi->s_stripe > 0 && sbi->s_cluster_ratio > 1 &&
      sbi->s_stripe % sbi->s_cluster_ratio != 0) {
    ext4_msg(sb, KERN_WARNING,
       "stripe (%lu) is not aligned with cluster size (%u), "
       "stripe is disabled",
       sbi->s_stripe, sbi->s_cluster_ratio);
    sbi->s_stripe = 0;
  }

I'll try to look into this a bit more and get back. Do let me know
if I missed anything.

Regards,
Ojaswin

>  
> -       if ((cr == CR_GOAL_LEN_FAST ||
> -            cr == CR_BEST_AVAIL_LEN) &&
> -           is_stripe_aligned)
> +       if (is_stripe_aligned)
>           ext4_mb_scan_aligned(ac, &e4b);
>  
>         if (ac->ac_status == AC_STATUS_CONTINUE)
> -- 
> 2.43.0
> 

Re: [PATCH] ext4: fix divide error in ext4_mb_regular_allocator

[Ojaswin Mujoo]

On Wed, Aug 14, 2024 at 10:26:47AM +0530, Ojaswin Mujoo wrote:
> On Wed, Aug 14, 2024 at 10:12:00AM +0800, Edward Adam Davis wrote:
> > Before determining that the goal length is a multiple of the stripe size,
> > check CR_GOAL_LEN_FAST and CR_BEST_AVAIL_LEN first.
> > 
> > Fixes: 1f6bc02f1848 ("ext4: fallback to complex scan if aligned scan doesn't work")
> > Reported-and-tested-by: syzbot+1ad8bac5af24d01e2cbd@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=1ad8bac5af24d01e2cbd
> > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > ---
> >  fs/ext4/mballoc.c | 7 +++----
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> > index 9dda9cd68ab2..451f92cde461 100644
> > --- a/fs/ext4/mballoc.c
> > +++ b/fs/ext4/mballoc.c
> > @@ -2928,13 +2928,12 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
> >       if (cr == CR_POWER2_ALIGNED)
> >         ext4_mb_simple_scan_group(ac, &e4b);
> >       else {
> > -       bool is_stripe_aligned = sbi->s_stripe &&
> > +       bool is_stripe_aligned = (cr == CR_GOAL_LEN_FAST ||
> > +         cr == CR_BEST_AVAIL_LEN) && sbi->s_stripe &&
> >           !(ac->ac_g_ex.fe_len %
> >             EXT4_B2C(sbi, sbi->s_stripe));
> 
> Hi Edward, 
> 
> Thanks for the patch. So I didn't get a chance to look at syszcaller
> report but assuming that EXT4_B2C(sbi, sbi->s_stripe) is becoming 0,
> I'm not understanding how is this patch fixing the bug?
> 
> It just seems to short circuit the actual bug but we might still hit it
> right? 
> 
> As for EXT4_B2C(stripe) becoming zero, I have 2 observations:
> 
> 1. We should definitely be using EXT4_NUM_B2C() here to make sure we
>    don't get 0 if stripe is less than cluster size.
> 
> 2. That being saidIm not sure if it's even possible for this to become zero
>    because we do check that stripe size is a multiple of cluster size in
>    ext4_fill_super, else we disable it:

So I figured out the issue. It is indeed possible for this to happen
since we forgot to add the below check on remount path in the following 
patch:

	c3defd99d58c ("ext4: treat stripe in block unit")

The patch at the end of the mail should fix this issue. Once syscaller
tests it I'll send out the patch addressing this as well as making the
change mentioned in point 1 of previous email.

> 
>   /*
>    * It's hard to get stripe aligned blocks if stripe is not aligned with
>    * cluster, just disable stripe and alert user to simpfy code and avoid
>    * stripe aligned allocation which will rarely successes.
>    */
>   if (sbi->s_stripe > 0 && sbi->s_cluster_ratio > 1 &&
>       sbi->s_stripe % sbi->s_cluster_ratio != 0) {
>     ext4_msg(sb, KERN_WARNING,
>        "stripe (%lu) is not aligned with cluster size (%u), "
>        "stripe is disabled",
>        sbi->s_stripe, sbi->s_cluster_ratio);
>     sbi->s_stripe = 0;
>   }

We disable stripe size in __ext4_fill_super if it is not a multiple of
the cluster ratio however this check is missed when trying to remount.
This can leave us with cases where stripe < cluster_ratio after
remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some
unforeseen bugs like divide by 0.

Fix that by adding the check in remount path as well.

Additionally, change the users of EXT4_B2C(sbi->s_stripe) to
EXT4_NUM_B2C() so that if we ever accidentally hit this again, we can
avoid the value becoming 0. This should not change existing functionality.

#syz test: https://github.com/torvalds/linux master

Reported-by: syzbot+1ad8bac5af24d01e2cbd@syzkaller.appspotmail.com
Fixes: c3defd99d58c ("ext4: treat stripe in block unit")
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
---
 fs/ext4/super.c | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index e72145c4ae5a..8ca6bbc337a6 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -5165,6 +5165,18 @@ static int ext4_block_group_meta_init(struct super_block *sb, int silent)
 	return 0;
 }
 
+/*
+ * It's hard to get stripe aligned blocks if stripe is not aligned with
+ * cluster, just disable stripe and alert user to simpfy code and avoid
+ * stripe aligned allocation which will rarely successes.
+ */
+static bool ext4_is_stripe_incompatible(struct super_block *sb, unsigned long stripe)
+{
+	struct ext4_sb_info *sbi = EXT4_SB(sb);
+	return (stripe > 0 && sbi->s_cluster_ratio > 1 &&
+		stripe % sbi->s_cluster_ratio != 0);
+}
+
 static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
 {
 	struct ext4_super_block *es = NULL;
@@ -5272,13 +5284,7 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
 		goto failed_mount3;
 
 	sbi->s_stripe = ext4_get_stripe_size(sbi);
-	/*
-	 * It's hard to get stripe aligned blocks if stripe is not aligned with
-	 * cluster, just disable stripe and alert user to simpfy code and avoid
-	 * stripe aligned allocation which will rarely successes.
-	 */
-	if (sbi->s_stripe > 0 && sbi->s_cluster_ratio > 1 &&
-	    sbi->s_stripe % sbi->s_cluster_ratio != 0) {
+	if (ext4_is_stripe_incompatible(sb, sbi->s_stripe)) {
 		ext4_msg(sb, KERN_WARNING,
 			 "stripe (%lu) is not aligned with cluster size (%u), "
 			 "stripe is disabled",
@@ -6441,6 +6447,15 @@ static int __ext4_remount(struct fs_context *fc, struct super_block *sb)
 
 	}
 
+	if (ctx->spec & EXT4_SPEC_s_stripe &&
+	    ext4_is_stripe_incompatible(sb, ctx->s_stripe)) {
+		ext4_msg(sb, KERN_WARNING,
+			 "stripe (%lu) is not aligned with cluster size (%u), "
+			 "stripe is disabled",
+			 ctx->s_stripe, sbi->s_cluster_ratio);
+		ctx->s_stripe = 0;
+	}
+
 	/*
 	 * Changing the DIOREAD_NOLOCK or DELALLOC mount options may cause
 	 * two calls to ext4_should_dioread_nolock() to return inconsistent
-- 
2.39.3

Re: [syzbot] [ext4?] divide error in ext4_mb_regular_allocator

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+1ad8bac5af24d01e2cbd@syzkaller.appspotmail.com
Tested-by: syzbot+1ad8bac5af24d01e2cbd@syzkaller.appspotmail.com

Tested on:

commit:         e724918b Merge tag 'hardening-v6.11-rc4' of git://git...
git tree:       https://github.com/torvalds/linux master
console output: https://syzkaller.appspot.com/x/log.txt?x=123767d9980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=92c0312151c4e32e
dashboard link: https://syzkaller.appspot.com/bug?extid=1ad8bac5af24d01e2cbd
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=15c916d5980000

Note: testing is done by a robot and is best-effort only.