[syzbot] [ext4?] WARNING in __folio_mark_dirty (3)

[syzbot] [ext4?] WARNING in __folio_mark_dirty (3)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    23cb64fb7625 Merge tag 'soc-fixes-6.18-3' of git://git.ker..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1287997c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=38a0c4cddc846161
dashboard link: https://syzkaller.appspot.com/bug?extid=b0a0670332b6b3230a0a
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=172cd658580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15378484580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/a14ebce6c664/disk-23cb64fb.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/7703c3032e2f/vmlinux-23cb64fb.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a16c5b94924d/bzImage-23cb64fb.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/4fa9525269b6/mount_0.gz
  fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=11d42a12580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com

EXT4-fs error (device loop0): ext4_ext_remove_space:2955: inode #15: comm syz.0.51: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 2, max 4(4), depth 0(0)
EXT4-fs error (device loop0) in ext4_setattr:6050: Corrupt filesystem
EXT4-fs error (device loop0): ext4_validate_block_bitmap:441: comm syz.0.51: bg 0: block 112: padding at end of block bitmap is not set
EXT4-fs error (device loop0): ext4_map_blocks:778: inode #15: block 3: comm syz.0.51: lblock 3 mapped to illegal pblock 3 (length 1)
EXT4-fs error (device loop0): ext4_ext_remove_space:2955: inode #15: comm syz.0.51: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 2, max 4(4), depth 0(0)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 6107 at mm/page-writeback.c:2716 __folio_mark_dirty+0x1fb/0xe20 mm/page-writeback.c:2716
Modules linked in:
CPU: 0 UID: 0 PID: 6107 Comm: syz.0.51 Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:__folio_mark_dirty+0x1fb/0xe20 mm/page-writeback.c:2716
Code: 3c 38 00 74 08 48 89 df e8 52 a7 26 00 4c 8b 33 4c 89 f6 48 83 e6 08 31 ff e8 d1 ed c4 ff 49 83 e6 08 75 1c e8 66 e8 c4 ff 90 <0f> 0b 90 eb 16 e8 5b e8 c4 ff e9 7e 07 00 00 e8 51 e8 c4 ff eb 05
RSP: 0018:ffffc90003a079d0 EFLAGS: 00010293
RAX: ffffffff81f9c4ea RBX: ffffea0001213400 RCX: ffff888025260000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: dffffc0000000000 R11: fffff94000242681 R12: ffff8880416cb4f0
R13: ffff8880416cb4e8 R14: 0000000000000000 R15: dffffc0000000000
FS:  0000555587ebe500(0000) GS:ffff888126df7000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000440 CR3: 000000002e288000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 block_dirty_folio+0x17a/0x1d0 fs/buffer.c:754
 fault_dirty_shared_page+0x103/0x570 mm/memory.c:3519
 wp_page_shared mm/memory.c:3906 [inline]
 do_wp_page+0x263e/0x4930 mm/memory.c:4109
 handle_pte_fault mm/memory.c:6211 [inline]
 __handle_mm_fault mm/memory.c:6336 [inline]
 handle_mm_fault+0x97c/0x3400 mm/memory.c:6505
 do_user_addr_fault+0xa7c/0x1380 arch/x86/mm/fault.c:1336
 handle_page_fault arch/x86/mm/fault.c:1476 [inline]
 exc_page_fault+0x82/0x100 arch/x86/mm/fault.c:1532
 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
RIP: 0033:0x7f385fe87398
Code: fc 89 37 c3 c5 fa 6f 06 c5 fa 6f 4c 16 f0 c5 fa 7f 07 c5 fa 7f 4c 17 f0 c3 66 0f 1f 84 00 00 00 00 00 48 8b 4c 16 f8 48 8b 36 <48> 89 37 48 89 4c 17 f8 c3 c5 fe 6f 54 16 e0 c5 fe 6f 5c 16 c0 c5
RSP: 002b:00007ffd3b8738f8 EFLAGS: 00010246
RAX: 0000200000000440 RBX: 0000000000000004 RCX: 0030656c69662f2e
RDX: 0000000000000008 RSI: 0030656c69662f2e RDI: 0000200000000440
RBP: 0000000000000000 R08: 0000001b2d820000 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000009 R12: 00007f3860115fac
R13: 00007f3860115fa0 R14: fffffffffffffffe R15: 0000000000000004
 </TASK>


---
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.

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?] WARNING in __folio_mark_dirty (3)

[Andrew Morton]

On Thu, 20 Nov 2025 08:41:31 -0800 syzbot <syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com> wrote:

> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    23cb64fb7625 Merge tag 'soc-fixes-6.18-3' of git://git.ker..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1287997c580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=38a0c4cddc846161
> dashboard link: https://syzkaller.appspot.com/bug?extid=b0a0670332b6b3230a0a
> compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=172cd658580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15378484580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/a14ebce6c664/disk-23cb64fb.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/7703c3032e2f/vmlinux-23cb64fb.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/a16c5b94924d/bzImage-23cb64fb.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/4fa9525269b6/mount_0.gz
>   fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=11d42a12580000)
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com

Thanks.

: void __folio_mark_dirty(struct folio *folio, struct address_space *mapping,
: 			     int warn)
: {
: 	unsigned long flags;
: 
: 	/*
: 	 * Shmem writeback relies on swap, and swap writeback is LRU based,
: 	 * not using the dirty mark.
: 	 */
: 	VM_WARN_ON_ONCE(folio_test_swapcache(folio) || shmem_mapping(mapping));
: 
: 	xa_lock_irqsave(&mapping->i_pages, flags);
: 	if (folio->mapping) {	/* Race with truncate? */
: 		WARN_ON_ONCE(warn && !folio_test_uptodate(folio));

this

: 		folio_account_dirtied(folio, mapping);
: 		__xa_set_mark(&mapping->i_pages, folio->index,
: 			      PAGECACHE_TAG_DIRTY);
: 	}
: 	xa_unlock_irqrestore(&mapping->i_pages, flags);
: }

I'm guessing that ext4 permitted a non-uptodate folio to find its way
into the blockdev mapping then the pagefault code tried to modify it
and got upset.


> EXT4-fs error (device loop0): ext4_ext_remove_space:2955: inode #15: comm syz.0.51: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 2, max 4(4), depth 0(0)
> EXT4-fs error (device loop0) in ext4_setattr:6050: Corrupt filesystem
> EXT4-fs error (device loop0): ext4_validate_block_bitmap:441: comm syz.0.51: bg 0: block 112: padding at end of block bitmap is not set
> EXT4-fs error (device loop0): ext4_map_blocks:778: inode #15: block 3: comm syz.0.51: lblock 3 mapped to illegal pblock 3 (length 1)
> EXT4-fs error (device loop0): ext4_ext_remove_space:2955: inode #15: comm syz.0.51: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 2, max 4(4), depth 0(0)
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 6107 at mm/page-writeback.c:2716 __folio_mark_dirty+0x1fb/0xe20 mm/page-writeback.c:2716
> Modules linked in:
> CPU: 0 UID: 0 PID: 6107 Comm: syz.0.51 Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
> RIP: 0010:__folio_mark_dirty+0x1fb/0xe20 mm/page-writeback.c:2716
> Code: 3c 38 00 74 08 48 89 df e8 52 a7 26 00 4c 8b 33 4c 89 f6 48 83 e6 08 31 ff e8 d1 ed c4 ff 49 83 e6 08 75 1c e8 66 e8 c4 ff 90 <0f> 0b 90 eb 16 e8 5b e8 c4 ff e9 7e 07 00 00 e8 51 e8 c4 ff eb 05
> RSP: 0018:ffffc90003a079d0 EFLAGS: 00010293
> RAX: ffffffff81f9c4ea RBX: ffffea0001213400 RCX: ffff888025260000
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
> R10: dffffc0000000000 R11: fffff94000242681 R12: ffff8880416cb4f0
> R13: ffff8880416cb4e8 R14: 0000000000000000 R15: dffffc0000000000
> FS:  0000555587ebe500(0000) GS:ffff888126df7000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000200000000440 CR3: 000000002e288000 CR4: 00000000003526f0
> Call Trace:
>  <TASK>
>  block_dirty_folio+0x17a/0x1d0 fs/buffer.c:754
>  fault_dirty_shared_page+0x103/0x570 mm/memory.c:3519
>  wp_page_shared mm/memory.c:3906 [inline]
>  do_wp_page+0x263e/0x4930 mm/memory.c:4109
>  handle_pte_fault mm/memory.c:6211 [inline]
>  __handle_mm_fault mm/memory.c:6336 [inline]
>  handle_mm_fault+0x97c/0x3400 mm/memory.c:6505
>  do_user_addr_fault+0xa7c/0x1380 arch/x86/mm/fault.c:1336
>  handle_page_fault arch/x86/mm/fault.c:1476 [inline]
>  exc_page_fault+0x82/0x100 arch/x86/mm/fault.c:1532
>  asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
> RIP: 0033:0x7f385fe87398
> Code: fc 89 37 c3 c5 fa 6f 06 c5 fa 6f 4c 16 f0 c5 fa 7f 07 c5 fa 7f 4c 17 f0 c3 66 0f 1f 84 00 00 00 00 00 48 8b 4c 16 f8 48 8b 36 <48> 89 37 48 89 4c 17 f8 c3 c5 fe 6f 54 16 e0 c5 fe 6f 5c 16 c0 c5
> RSP: 002b:00007ffd3b8738f8 EFLAGS: 00010246
> RAX: 0000200000000440 RBX: 0000000000000004 RCX: 0030656c69662f2e
> RDX: 0000000000000008 RSI: 0030656c69662f2e RDI: 0000200000000440
> RBP: 0000000000000000 R08: 0000001b2d820000 R09: 0000000000000001
> R10: 0000000000000001 R11: 0000000000000009 R12: 00007f3860115fac
> R13: 00007f3860115fa0 R14: fffffffffffffffe R15: 0000000000000004
>  </TASK>

Re: [syzbot] [ext4?] WARNING in __folio_mark_dirty (3)

[Matthew Wilcox]

On Fri, Nov 21, 2025 at 10:11:55AM -0800, Andrew Morton wrote:
> On Thu, 20 Nov 2025 08:41:31 -0800 syzbot <syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com> wrote:
> : void __folio_mark_dirty(struct folio *folio, struct address_space *mapping,
> : 			     int warn)
> : {
> : 	unsigned long flags;
> : 
> : 	/*
> : 	 * Shmem writeback relies on swap, and swap writeback is LRU based,
> : 	 * not using the dirty mark.
> : 	 */
> : 	VM_WARN_ON_ONCE(folio_test_swapcache(folio) || shmem_mapping(mapping));
> : 
> : 	xa_lock_irqsave(&mapping->i_pages, flags);
> : 	if (folio->mapping) {	/* Race with truncate? */
> : 		WARN_ON_ONCE(warn && !folio_test_uptodate(folio));
> 
> this
> 
> : 		folio_account_dirtied(folio, mapping);
> : 		__xa_set_mark(&mapping->i_pages, folio->index,
> : 			      PAGECACHE_TAG_DIRTY);
> : 	}
> : 	xa_unlock_irqrestore(&mapping->i_pages, flags);
> : }
> 
> I'm guessing that ext4 permitted a non-uptodate folio to find its way
> into the blockdev mapping then the pagefault code tried to modify it
> and got upset.

I think you're right, but the reason it's upset is that it found a
!uptodate folio that was mapped into userspace, and that's not supposed
to happen!  Presumably it was uptodate at the point it was initially
faulted in, then (perhaps when the error happened?) somebody cleared the
uptodate flag without unmapping the folio.

Hm.  I wonder if we should do this to catch the offender:

@@ -831,7 +833,17 @@ static __always_inline void SetPageUptodate(struct page *pa
ge)
        folio_mark_uptodate((struct folio *)page);
 }

-CLEARPAGEFLAG(Uptodate, uptodate, PF_NO_TAIL)
+static __always_inline void folio_clear_uptodate(struct folio *folio)
+{
+       VM_BUG_ON_FOLIO(folio_mapped(folio), folio);
+       clear_bit(PG_uptodate, folio_flags(folio, 0));
+}
+
+static __always_inline void ClearPageUptodate(struct page *page)
+{
+       VM_BUG_ON_PGFLAGS(PageTail(page), page);
+       folio_clear_uptodate((struct folio *)page);
+}

 void __folio_start_writeback(struct folio *folio, bool keep_write);
 void set_page_writeback(struct page *page);

... it doesn't actually compile because folio_mapcount() is in mm.h
so the declaration is out of order, but I can invest smoe effort into
making that work if you think it's worth doing.

> > EXT4-fs error (device loop0): ext4_ext_remove_space:2955: inode #15: comm syz.0.51: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 2, max 4(4), depth 0(0)
> > EXT4-fs error (device loop0) in ext4_setattr:6050: Corrupt filesystem
> > EXT4-fs error (device loop0): ext4_validate_block_bitmap:441: comm syz.0.51: bg 0: block 112: padding at end of block bitmap is not set
> > EXT4-fs error (device loop0): ext4_map_blocks:778: inode #15: block 3: comm syz.0.51: lblock 3 mapped to illegal pblock 3 (length 1)
> > EXT4-fs error (device loop0): ext4_ext_remove_space:2955: inode #15: comm syz.0.51: pblk 0 bad header/extent: invalid extent entries - magic f30a, entries 2, max 4(4), depth 0(0)
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 6107 at mm/page-writeback.c:2716 __folio_mark_dirty+0x1fb/0xe20 mm/page-writeback.c:2716
> > Modules linked in:
> > CPU: 0 UID: 0 PID: 6107 Comm: syz.0.51 Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
> > RIP: 0010:__folio_mark_dirty+0x1fb/0xe20 mm/page-writeback.c:2716
> > Code: 3c 38 00 74 08 48 89 df e8 52 a7 26 00 4c 8b 33 4c 89 f6 48 83 e6 08 31 ff e8 d1 ed c4 ff 49 83 e6 08 75 1c e8 66 e8 c4 ff 90 <0f> 0b 90 eb 16 e8 5b e8 c4 ff e9 7e 07 00 00 e8 51 e8 c4 ff eb 05
> > RSP: 0018:ffffc90003a079d0 EFLAGS: 00010293
> > RAX: ffffffff81f9c4ea RBX: ffffea0001213400 RCX: ffff888025260000
> > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> > RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
> > R10: dffffc0000000000 R11: fffff94000242681 R12: ffff8880416cb4f0
> > R13: ffff8880416cb4e8 R14: 0000000000000000 R15: dffffc0000000000
> > FS:  0000555587ebe500(0000) GS:ffff888126df7000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000200000000440 CR3: 000000002e288000 CR4: 00000000003526f0
> > Call Trace:
> >  <TASK>
> >  block_dirty_folio+0x17a/0x1d0 fs/buffer.c:754
> >  fault_dirty_shared_page+0x103/0x570 mm/memory.c:3519
> >  wp_page_shared mm/memory.c:3906 [inline]
> >  do_wp_page+0x263e/0x4930 mm/memory.c:4109
> >  handle_pte_fault mm/memory.c:6211 [inline]
> >  __handle_mm_fault mm/memory.c:6336 [inline]
> >  handle_mm_fault+0x97c/0x3400 mm/memory.c:6505
> >  do_user_addr_fault+0xa7c/0x1380 arch/x86/mm/fault.c:1336
> >  handle_page_fault arch/x86/mm/fault.c:1476 [inline]
> >  exc_page_fault+0x82/0x100 arch/x86/mm/fault.c:1532
> >  asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
> > RIP: 0033:0x7f385fe87398
> > Code: fc 89 37 c3 c5 fa 6f 06 c5 fa 6f 4c 16 f0 c5 fa 7f 07 c5 fa 7f 4c 17 f0 c3 66 0f 1f 84 00 00 00 00 00 48 8b 4c 16 f8 48 8b 36 <48> 89 37 48 89 4c 17 f8 c3 c5 fe 6f 54 16 e0 c5 fe 6f 5c 16 c0 c5
> > RSP: 002b:00007ffd3b8738f8 EFLAGS: 00010246
> > RAX: 0000200000000440 RBX: 0000000000000004 RCX: 0030656c69662f2e
> > RDX: 0000000000000008 RSI: 0030656c69662f2e RDI: 0000200000000440
> > RBP: 0000000000000000 R08: 0000001b2d820000 R09: 0000000000000001
> > R10: 0000000000000001 R11: 0000000000000009 R12: 00007f3860115fac
> > R13: 00007f3860115fa0 R14: fffffffffffffffe R15: 0000000000000004
> >  </TASK>
> 

Re: [syzbot] [ext4?] WARNING in __folio_mark_dirty (3)

[Andrew Morton]

On Fri, 21 Nov 2025 19:02:18 +0000 Matthew Wilcox <willy@infradead.org> wrote:

> > I'm guessing that ext4 permitted a non-uptodate folio to find its way
> > into the blockdev mapping then the pagefault code tried to modify it
> > and got upset.
> 
> I think you're right, but the reason it's upset is that it found a
> !uptodate folio that was mapped into userspace, and that's not supposed
> to happen!  Presumably it was uptodate at the point it was initially
> faulted in, then (perhaps when the error happened?) somebody cleared the
> uptodate flag without unmapping the folio.
> 
> Hm.  I wonder if we should do this to catch the offender:
> 
> @@ -831,7 +833,17 @@ static __always_inline void SetPageUptodate(struct page *pa
> ge)
>         folio_mark_uptodate((struct folio *)page);
>  }
> 
> -CLEARPAGEFLAG(Uptodate, uptodate, PF_NO_TAIL)
> +static __always_inline void folio_clear_uptodate(struct folio *folio)
> +{
> +       VM_BUG_ON_FOLIO(folio_mapped(folio), folio);
> +       clear_bit(PG_uptodate, folio_flags(folio, 0));
> +}
> +
> +static __always_inline void ClearPageUptodate(struct page *page)
> +{
> +       VM_BUG_ON_PGFLAGS(PageTail(page), page);
> +       folio_clear_uptodate((struct folio *)page);
> +}
> 
>  void __folio_start_writeback(struct folio *folio, bool keep_write);
>  void set_page_writeback(struct page *page);

We have a reproducer, fortunately.

> ... it doesn't actually compile because folio_mapcount() is in mm.h
> so the declaration is out of order, but I can invest smoe effort into
> making that work if you think it's worth doing.

It's a shame to add more debug stuff into oft-called inline functions.

Maybe some hacky thing which uninlines these functions and adds the
debug?  I can slip that into -next until we fix the bug then throw the
debug patch away.

Of course, there may be other filesystems which are tripped up by this.
Once we fully understand the failure we can decide whether it's worth
adding the extra debug to mainline?

Re: [syzbot] [ext4?] WARNING in __folio_mark_dirty (3)

[Theodore Tso]

On Thu, Nov 20, 2025 at 08:41:31AM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    23cb64fb7625 Merge tag 'soc-fixes-6.18-3' of git://git.ker..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1287997c580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=38a0c4cddc846161
> dashboard link: https://syzkaller.appspot.com/bug?extid=b0a0670332b6b3230a0a
> compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=172cd658580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15378484580000

Not reproducing locally, so let's see if Syzbot can reproduce in its environment....

#syz test https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev

Re: [syzbot] [ext4?] WARNING in __folio_mark_dirty (3)

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in __folio_mark_dirty

------------[ cut here ]------------
WARNING: CPU: 1 PID: 6740 at mm/page-writeback.c:2716 __folio_mark_dirty+0x1fb/0xe20 mm/page-writeback.c:2716
Modules linked in:
CPU: 1 UID: 0 PID: 6740 Comm: syz.0.31 Not tainted syzkaller #0 PREEMPT_{RT,(full)} 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:__folio_mark_dirty+0x1fb/0xe20 mm/page-writeback.c:2716
Code: 3c 38 00 74 08 48 89 df e8 d2 a1 26 00 4c 8b 33 4c 89 f6 48 83 e6 08 31 ff e8 71 ef c4 ff 49 83 e6 08 75 1c e8 06 ea c4 ff 90 <0f> 0b 90 eb 16 e8 fb e9 c4 ff e9 7e 07 00 00 e8 f1 e9 c4 ff eb 05
RSP: 0018:ffffc90003a979d0 EFLAGS: 00010293
RAX: ffffffff81f9d61a RBX: ffffea0001056b40 RCX: ffff888020775a00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: dffffc0000000000 R11: fffff9400020ad69 R12: ffff88805b014d00
R13: ffff88805b014cf8 R14: 0000000000000000 R15: dffffc0000000000
FS:  0000555575052500(0000) GS:ffff888126ef6000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000440 CR3: 0000000036d66000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 block_dirty_folio+0x17a/0x1d0 fs/buffer.c:754
 fault_dirty_shared_page+0x103/0x570 mm/memory.c:3518
 wp_page_shared mm/memory.c:3905 [inline]
 do_wp_page+0x263e/0x4930 mm/memory.c:4108
 handle_pte_fault mm/memory.c:6193 [inline]
 __handle_mm_fault mm/memory.c:6318 [inline]
 handle_mm_fault+0x97c/0x3400 mm/memory.c:6487
 do_user_addr_fault+0xa7c/0x1380 arch/x86/mm/fault.c:1336
 handle_page_fault arch/x86/mm/fault.c:1476 [inline]
 exc_page_fault+0x82/0x100 arch/x86/mm/fault.c:1532
 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
RIP: 0033:0x7f1eba837398
Code: fc 89 37 c3 c5 fa 6f 06 c5 fa 6f 4c 16 f0 c5 fa 7f 07 c5 fa 7f 4c 17 f0 c3 66 0f 1f 84 00 00 00 00 00 48 8b 4c 16 f8 48 8b 36 <48> 89 37 48 89 4c 17 f8 c3 c5 fe 6f 54 16 e0 c5 fe 6f 5c 16 c0 c5
RSP: 002b:00007ffd39d5fc68 EFLAGS: 00010246
RAX: 0000200000000440 RBX: 0000000000000004 RCX: 0030656c69662f2e
RDX: 0000000000000008 RSI: 0030656c69662f2e RDI: 0000200000000440
RBP: 00007f1ebaac7da0 R08: 0000001b2cc20000 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000009 R12: 00007f1ebaac5fac
R13: 00007f1ebaac5fa0 R14: fffffffffffffffe R15: 00007ffd39d5fd80
 </TASK>


Tested on:

commit:         6fb67ac8 ext4: drop the TODO comment in ext4_es_insert..
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
console output: https://syzkaller.appspot.com/x/log.txt?x=16156192580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=41ad820f608cb833
dashboard link: https://syzkaller.appspot.com/bug?extid=b0a0670332b6b3230a0a
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

Note: no patches were applied.