* [BUG] ext4: NULL/invalid pointer dereference in ext4_writepages() during generic/039 @ 2026-08-03 4:47 Venkat Rao Bagalkote 2026-08-03 6:52 ` Ojaswin Mujoo 0 siblings, 1 reply; 5+ messages in thread From: Venkat Rao Bagalkote @ 2026-08-03 4:47 UTC (permalink / raw) To: linux-ext4, tytso, adilger.kernel Cc: linux-fsdevel, LKML, ojaswin, Christophe Leroy, Madhavan Srinivasan Hi, I am seeing a reproducible kernel crash while running xfstests generic/039 on powerpc. The crash happens during ext4 journal recovery while mounting the filesystem. The fault occurs inside ext4_writepages() and appears to dereference a userspace-looking address. Test environment ---------------- Kernel: 7.2.0-rc5-next-20260731 Architecture: powerpc64le Platform: IBM Power9 (pSeries) Machine: IBM,8375-42A FW950.80 (VL950_131) Config highlights: PAGE_SIZE=64K MMU=Hash PREEMPTLAZY=y Workload -------- xfstests generic/039 Log excerpt: run fstests generic/039 at 2026-08-03 00:22:44 Crash ----- [ 615.063689] Kernel attempted to read user page (fe73f0000) - exploit attempt? (uid: 0) [ 615.063714] BUG: Unable to handle kernel data access on read at 0xfe73f0000 [ 615.063723] Faulting instruction address: 0xc008000015b0ed24 [ 615.063731] Oops: Kernel access of bad area, sig: 11 [#1] The faulting instruction is: ext4_writepages+0x12c/0x3a0 Relevant call trace: ext4_writepages do_writepages __writeback_single_inode writeback_single_inode write_inode_now iput_final ext4_fc_replay do_one_pass jbd2_journal_recover jbd2_journal_load ext4_load_journal ext4_load_and_init_journal __ext4_fill_super ext4_fill_super get_tree_bdev_flags ext4_get_tree vfs_get_tree vfs_cmd_create __do_sys_fsconfig Full trace: [ 615.064100] NIP [c008000015b0ed24] ext4_writepages+0x12c/0x3a0 [ext4] [ 615.064360] Call Trace: [ 615.064383] do_writepages+0x190/0x330 [ 615.064395] __writeback_single_inode+0x9c/0x9e0 [ 615.064411] writeback_single_inode+0x18c/0x2b0 [ 615.064425] write_inode_now+0xc0/0x100 [ 615.064439] iput_final+0x10c/0x300 [ 615.064451] ext4_fc_replay+0x374/0xdd0 [ext4] [ 615.064583] do_one_pass+0x9bc/0x1370 [jbd2] [ 615.064627] jbd2_journal_recover[0x358/0x400 [jbd2] [ [jbd2615.064670] jbd2_journal_load/0x110 [jbd2] [ 615.064712] ext4_load_journal+0x2a0/0xb00 [ext4] [ 615.064844] ext4_load_and_init_journal+0x6c/0x660 [ext4] [ 615.064976] __ext4_fill_super+0x20b0/0x23a0 [ext4] Registers: DAR: 0x0000000fe73f0000 DSISR: 0x40000000 The address being dereferenced (0xfe73f0000) looks like a userspace address and triggers: "Kernel attempted to read user page - exploit attempt?" Filesystem messages immediately prior to the crash: [ 614.718310] EXT4-fs (loop0): mounted filesystem ee09878a-da42-4d97-81ed-1b9616af2fb4 r/w with ordered data mode. Quota mode: journalled. [ 614.984409] EXT4-fs (dm-0): mounted filesystem b60397dc-c40f-4c75-bba9-bfc21f3a905a r/w with ordered data mode. Quota mode: journalled. [ 615.029979] EXT4-fs (dm-0): unmounting filesystem b60397dc-c40f-4c75-bba9-bfc21f3a905a. Meanwhile, I will attempt bisection. If you happen to fix this issue, please add below tag. Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Thanks, Venkat. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG] ext4: NULL/invalid pointer dereference in ext4_writepages() during generic/039 2026-08-03 4:47 [BUG] ext4: NULL/invalid pointer dereference in ext4_writepages() during generic/039 Venkat Rao Bagalkote @ 2026-08-03 6:52 ` Ojaswin Mujoo 2026-08-03 19:48 ` Ojaswin Mujoo 0 siblings, 1 reply; 5+ messages in thread From: Ojaswin Mujoo @ 2026-08-03 6:52 UTC (permalink / raw) To: Venkat Rao Bagalkote Cc: linux-ext4, tytso, adilger.kernel, linux-fsdevel, LKML, Christophe Leroy, Madhavan Srinivasan On Mon, Aug 03, 2026 at 10:17:35AM +0530, Venkat Rao Bagalkote wrote: > Hi, > > I am seeing a reproducible kernel crash while running xfstests generic/039 > on powerpc. > > The crash happens during ext4 journal recovery while mounting the > filesystem. The fault occurs inside ext4_writepages() and appears to > dereference a userspace-looking address. > > Test environment > ---------------- > Kernel: > 7.2.0-rc5-next-20260731 > > Architecture: > powerpc64le > > Platform: > IBM Power9 (pSeries) > > Machine: > IBM,8375-42A > FW950.80 (VL950_131) > > Config highlights: > PAGE_SIZE=64K > MMU=Hash > PREEMPTLAZY=y > > Workload > -------- > xfstests generic/039 > > Log excerpt: > run fstests generic/039 at 2026-08-03 00:22:44 > > Crash > ----- > [ 615.063689] Kernel attempted to read user page (fe73f0000) - exploit > attempt? (uid: 0) > [ 615.063714] BUG: Unable to handle kernel data access on read at > 0xfe73f0000 > [ 615.063723] Faulting instruction address: 0xc008000015b0ed24 > [ 615.063731] Oops: Kernel access of bad area, sig: 11 [#1] > > The faulting instruction is: > > ext4_writepages+0x12c/0x3a0 > > Relevant call trace: > > ext4_writepages > do_writepages > __writeback_single_inode > writeback_single_inode > write_inode_now > iput_final > ext4_fc_replay > do_one_pass > jbd2_journal_recover > jbd2_journal_load > ext4_load_journal > ext4_load_and_init_journal > __ext4_fill_super > ext4_fill_super > get_tree_bdev_flags > ext4_get_tree > vfs_get_tree > vfs_cmd_create > __do_sys_fsconfig > > Full trace: > > [ 615.064100] NIP [c008000015b0ed24] ext4_writepages+0x12c/0x3a0 [ext4] > [ 615.064360] Call Trace: > [ 615.064383] do_writepages+0x190/0x330 > [ 615.064395] __writeback_single_inode+0x9c/0x9e0 > [ 615.064411] writeback_single_inode+0x18c/0x2b0 > [ 615.064425] write_inode_now+0xc0/0x100 > [ 615.064439] iput_final+0x10c/0x300 > [ 615.064451] ext4_fc_replay+0x374/0xdd0 [ext4] > [ 615.064583] do_one_pass+0x9bc/0x1370 [jbd2] > [ 615.064627] jbd2_journal_recover[0x358/0x400 [jbd2] > [ [jbd2615.064670] jbd2_journal_load/0x110 [jbd2] > [ 615.064712] ext4_load_journal+0x2a0/0xb00 [ext4] > [ 615.064844] ext4_load_and_init_journal+0x6c/0x660 [ext4] > [ 615.064976] __ext4_fill_super+0x20b0/0x23a0 [ext4] > > Registers: > > DAR: 0x0000000fe73f0000 > DSISR: 0x40000000 > > The address being dereferenced (0xfe73f0000) looks like a userspace > address and triggers: > > "Kernel attempted to read user page - exploit attempt?" > > > Filesystem messages immediately prior to the crash: > > [ 614.718310] EXT4-fs (loop0): mounted filesystem > ee09878a-da42-4d97-81ed-1b9616af2fb4 r/w with ordered data mode. Quota mode: > journalled. > [ 614.984409] EXT4-fs (dm-0): mounted filesystem > b60397dc-c40f-4c75-bba9-bfc21f3a905a r/w with ordered data mode. Quota mode: > journalled. > [ 615.029979] EXT4-fs (dm-0): unmounting filesystem > b60397dc-c40f-4c75-bba9-bfc21f3a905a. > > > Meanwhile, I will attempt bisection. > > If you happen to fix this issue, please add below tag. > > Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> > Hey thanks for reporting this Venkat, I'll try to replicate this at my end. In the meantime, can you please share the complete Oops message and also your local.config. Thanks, ojaswin > > > Thanks, > Venkat. > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG] ext4: NULL/invalid pointer dereference in ext4_writepages() during generic/039 2026-08-03 6:52 ` Ojaswin Mujoo @ 2026-08-03 19:48 ` Ojaswin Mujoo 2026-08-04 10:41 ` Jan Kara 0 siblings, 1 reply; 5+ messages in thread From: Ojaswin Mujoo @ 2026-08-03 19:48 UTC (permalink / raw) To: Venkat Rao Bagalkote Cc: linux-ext4, tytso, adilger.kernel, linux-fsdevel, LKML, Christophe Leroy, Madhavan Srinivasan, Christian Brauner, Jan Kara On Mon, Aug 03, 2026 at 12:22:35PM +0530, Ojaswin Mujoo wrote: > On Mon, Aug 03, 2026 at 10:17:35AM +0530, Venkat Rao Bagalkote wrote: > > Hi, > > > > I am seeing a reproducible kernel crash while running xfstests generic/039 > > on powerpc. > > > > The crash happens during ext4 journal recovery while mounting the > > filesystem. The fault occurs inside ext4_writepages() and appears to > > dereference a userspace-looking address. > > > > Test environment > > ---------------- > > Kernel: > > 7.2.0-rc5-next-20260731 > > > > Architecture: > > powerpc64le > > > > Platform: > > IBM Power9 (pSeries) > > > > Machine: > > IBM,8375-42A > > FW950.80 (VL950_131) > > > > Config highlights: > > PAGE_SIZE=64K > > MMU=Hash > > PREEMPTLAZY=y > > > > Workload > > -------- > > xfstests generic/039 > > > > Log excerpt: > > run fstests generic/039 at 2026-08-03 00:22:44 > > > > Crash > > ----- > > [ 615.063689] Kernel attempted to read user page (fe73f0000) - exploit > > attempt? (uid: 0) > > [ 615.063714] BUG: Unable to handle kernel data access on read at > > 0xfe73f0000 > > [ 615.063723] Faulting instruction address: 0xc008000015b0ed24 > > [ 615.063731] Oops: Kernel access of bad area, sig: 11 [#1] > > > > The faulting instruction is: > > > > ext4_writepages+0x12c/0x3a0 > > > > Relevant call trace: > > > > ext4_writepages > > do_writepages > > __writeback_single_inode > > writeback_single_inode > > write_inode_now > > iput_final > > ext4_fc_replay > > do_one_pass > > jbd2_journal_recover > > jbd2_journal_load > > ext4_load_journal > > ext4_load_and_init_journal > > __ext4_fill_super > > ext4_fill_super > > get_tree_bdev_flags > > ext4_get_tree > > vfs_get_tree > > vfs_cmd_create > > __do_sys_fsconfig > > > > Full trace: > > > > [ 615.064100] NIP [c008000015b0ed24] ext4_writepages+0x12c/0x3a0 [ext4] > > [ 615.064360] Call Trace: > > [ 615.064383] do_writepages+0x190/0x330 > > [ 615.064395] __writeback_single_inode+0x9c/0x9e0 > > [ 615.064411] writeback_single_inode+0x18c/0x2b0 > > [ 615.064425] write_inode_now+0xc0/0x100 > > [ 615.064439] iput_final+0x10c/0x300 > > [ 615.064451] ext4_fc_replay+0x374/0xdd0 [ext4] > > [ 615.064583] do_one_pass+0x9bc/0x1370 [jbd2] > > [ 615.064627] jbd2_journal_recover[0x358/0x400 [jbd2] > > [ [jbd2615.064670] jbd2_journal_load/0x110 [jbd2] > > [ 615.064712] ext4_load_journal+0x2a0/0xb00 [ext4] > > [ 615.064844] ext4_load_and_init_journal+0x6c/0x660 [ext4] > > [ 615.064976] __ext4_fill_super+0x20b0/0x23a0 [ext4] > > > > Registers: > > > > DAR: 0x0000000fe73f0000 > > DSISR: 0x40000000 > > > > The address being dereferenced (0xfe73f0000) looks like a userspace > > address and triggers: > > > > "Kernel attempted to read user page - exploit attempt?" > > > > > > Filesystem messages immediately prior to the crash: > > > > [ 614.718310] EXT4-fs (loop0): mounted filesystem > > ee09878a-da42-4d97-81ed-1b9616af2fb4 r/w with ordered data mode. Quota mode: > > journalled. > > [ 614.984409] EXT4-fs (dm-0): mounted filesystem > > b60397dc-c40f-4c75-bba9-bfc21f3a905a r/w with ordered data mode. Quota mode: > > journalled. > > [ 615.029979] EXT4-fs (dm-0): unmounting filesystem > > b60397dc-c40f-4c75-bba9-bfc21f3a905a. > > > > > > Meanwhile, I will attempt bisection. > > > > If you happen to fix this issue, please add below tag. > > > > Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> > > > > Hey thanks for reporting this Venkat, I'll try to replicate this at my > end. > > In the meantime, can you please share the complete Oops message and also > your local.config. > > Thanks, > ojaswin (+cc Jan, Christian) Okay so I'm able to replicate this in an x86 machine as well with 4kb block size. The issue is replicable in vfs/vfs.all and is occurring after Jan's change to nojournal mode writeout [1], with fast_commit. The issue is as follows: __ext4_fill_super ext4_load_and_init_journal ... jbd2_journal_recover do_one_pass fc_do_one_pass ... ext4_fc_replay_unlink __ext4_unlink __ext4_mark_iloc_dirty if (sbi->s_journal == NULL) // s_journal is not set yet set_inode_metadata_writeback(inode); // sets I_METADATA_WRITEBACK iput(inode) iput_final(inode) ... writeback_single_inode __writeback_single_inode // since I_METADATA_WRITEBACK is set ... ext4_writepages ext4_writepages_down_read percpu_down_read(sbi->s_writepages_rwsem) <--- OOPS because this is initialized later in ext4_percpu_param_init() A simple fix seems to be to move ext4_percpu_param_init() call before ext4_load_journal() so that we can safely call ext4_writepages(). The below diff seems to be fixing the issue for me, does this look okay to you Jan? Also, venkat can you please help test this in your system: diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 2877a6cf6d09..6e05f191542c 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -5511,6 +5511,10 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb) goto failed_mount3a; } + err = ext4_percpu_param_init(sbi); + if (err) + goto failed_mount3a; + err = -EINVAL; /* * The first inode we look at is the journal inode. Don't try @@ -5659,10 +5663,6 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb) clear_opt2(sb, MB_OPTIMIZE_SCAN); } - err = ext4_percpu_param_init(sbi); - if (err) - goto failed_mount5; - err = ext4_mb_init(sb); if (err) { ext4_msg(sb, KERN_ERR, "failed to initialize mballoc (%d)", @@ -5764,7 +5764,6 @@ failed_mount8: __maybe_unused ext4_mb_release(sb); ext4_flex_groups_free(sbi); failed_mount5: - ext4_percpu_param_destroy(sbi); ext4_ext_release(sb); ext4_release_system_zone(sb); failed_mount4a: @@ -5785,6 +5784,7 @@ failed_mount8: __maybe_unused ext4_journal_destroy(sbi, sbi->s_journal); } failed_mount3a: + ext4_percpu_param_destroy(sbi); ext4_es_unregister_shrinker(sbi); failed_mount3: /* flush s_sb_upd_work before sbi destroy */ [1] https://lore.kernel.org/linux-ext4/20260727104923.3828017-37-jack@suse.cz/ > > > > > > Thanks, > > Venkat. > > ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [BUG] ext4: NULL/invalid pointer dereference in ext4_writepages() during generic/039 2026-08-03 19:48 ` Ojaswin Mujoo @ 2026-08-04 10:41 ` Jan Kara 2026-08-04 11:48 ` Ojaswin Mujoo 0 siblings, 1 reply; 5+ messages in thread From: Jan Kara @ 2026-08-04 10:41 UTC (permalink / raw) To: Ojaswin Mujoo Cc: Venkat Rao Bagalkote, linux-ext4, tytso, adilger.kernel, linux-fsdevel, LKML, Christophe Leroy, Madhavan Srinivasan, Christian Brauner, Jan Kara Hello! On Tue 04-08-26 01:18:49, Ojaswin Mujoo wrote: > On Mon, Aug 03, 2026 at 12:22:35PM +0530, Ojaswin Mujoo wrote: ... > > > Meanwhile, I will attempt bisection. > > > > > > If you happen to fix this issue, please add below tag. > > > > > > Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> > > > > > > > Hey thanks for reporting this Venkat, I'll try to replicate this at my > > end. > > > > In the meantime, can you please share the complete Oops message and also > > your local.config. > > > > Thanks, > > ojaswin > > (+cc Jan, Christian) > > Okay so I'm able to replicate this in an x86 machine as well with 4kb > block size. The issue is replicable in vfs/vfs.all and is occurring > after Jan's change to nojournal mode writeout [1], with fast_commit. > > The issue is as follows: > > __ext4_fill_super > ext4_load_and_init_journal > ... > jbd2_journal_recover > do_one_pass > fc_do_one_pass > ... > ext4_fc_replay_unlink > __ext4_unlink > __ext4_mark_iloc_dirty > if (sbi->s_journal == NULL) // s_journal is not set yet > set_inode_metadata_writeback(inode); // sets I_METADATA_WRITEBACK > iput(inode) > iput_final(inode) > ... > writeback_single_inode > __writeback_single_inode // since I_METADATA_WRITEBACK is set > ... > ext4_writepages > ext4_writepages_down_read > percpu_down_read(sbi->s_writepages_rwsem) > <--- OOPS because this is initialized > later in ext4_percpu_param_init() > > A simple fix seems to be to move ext4_percpu_param_init() call before > ext4_load_journal() so that we can safely call ext4_writepages(). The > below diff seems to be fixing the issue for me, does this look okay to > you Jan? Thanks for report and the analysis! I didn't realize fastcommit replay actually runs in nojournal mode. I don't think moving ext4_percpu_param_init() is really correct - it initializes also directory, free blocks and other counters and those depend on filesystem already being in consistent state (i.e., after journal replay). We would have to move just s_writepages_rwsem initialization. That being said I think a nicer fix is to just avoid setting I_METADATA_WRITEBACK flag during fastcommit replay. We don't really need it for anything during replay (it flushes the whole bdev anyway), it just slows things down by more frequent buffer writeout. I've tested that change and it fixes the problem for me. I'll post it officially shortly. Honza > Also, venkat can you please help test this in your system: > > diff --git a/fs/ext4/super.c b/fs/ext4/super.c > index 2877a6cf6d09..6e05f191542c 100644 > --- a/fs/ext4/super.c > +++ b/fs/ext4/super.c > @@ -5511,6 +5511,10 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb) > goto failed_mount3a; > } > > + err = ext4_percpu_param_init(sbi); > + if (err) > + goto failed_mount3a; > + > err = -EINVAL; > /* > * The first inode we look at is the journal inode. Don't try > @@ -5659,10 +5663,6 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb) > clear_opt2(sb, MB_OPTIMIZE_SCAN); > } > > - err = ext4_percpu_param_init(sbi); > - if (err) > - goto failed_mount5; > - > err = ext4_mb_init(sb); > if (err) { > ext4_msg(sb, KERN_ERR, "failed to initialize mballoc (%d)", > @@ -5764,7 +5764,6 @@ failed_mount8: __maybe_unused > ext4_mb_release(sb); > ext4_flex_groups_free(sbi); > failed_mount5: > - ext4_percpu_param_destroy(sbi); > ext4_ext_release(sb); > ext4_release_system_zone(sb); > failed_mount4a: > @@ -5785,6 +5784,7 @@ failed_mount8: __maybe_unused > ext4_journal_destroy(sbi, sbi->s_journal); > } > failed_mount3a: > + ext4_percpu_param_destroy(sbi); > ext4_es_unregister_shrinker(sbi); > failed_mount3: > /* flush s_sb_upd_work before sbi destroy */ > > [1] https://lore.kernel.org/linux-ext4/20260727104923.3828017-37-jack@suse.cz/ > > > > > > > > > Thanks, > > > Venkat. > > > -- Jan Kara <jack@suse.com> SUSE Labs, CR ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG] ext4: NULL/invalid pointer dereference in ext4_writepages() during generic/039 2026-08-04 10:41 ` Jan Kara @ 2026-08-04 11:48 ` Ojaswin Mujoo 0 siblings, 0 replies; 5+ messages in thread From: Ojaswin Mujoo @ 2026-08-04 11:48 UTC (permalink / raw) To: Jan Kara Cc: Venkat Rao Bagalkote, linux-ext4, tytso, adilger.kernel, linux-fsdevel, LKML, Christophe Leroy, Madhavan Srinivasan, Christian Brauner On Tue, Aug 04, 2026 at 12:41:09PM +0200, Jan Kara wrote: > Hello! > > On Tue 04-08-26 01:18:49, Ojaswin Mujoo wrote: > > On Mon, Aug 03, 2026 at 12:22:35PM +0530, Ojaswin Mujoo wrote: > ... > > > > Meanwhile, I will attempt bisection. > > > > > > > > If you happen to fix this issue, please add below tag. > > > > > > > > Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> > > > > > > > > > > Hey thanks for reporting this Venkat, I'll try to replicate this at my > > > end. > > > > > > In the meantime, can you please share the complete Oops message and also > > > your local.config. > > > > > > Thanks, > > > ojaswin > > > > (+cc Jan, Christian) > > > > Okay so I'm able to replicate this in an x86 machine as well with 4kb > > block size. The issue is replicable in vfs/vfs.all and is occurring > > after Jan's change to nojournal mode writeout [1], with fast_commit. > > > > The issue is as follows: > > > > __ext4_fill_super > > ext4_load_and_init_journal > > ... > > jbd2_journal_recover > > do_one_pass > > fc_do_one_pass > > ... > > ext4_fc_replay_unlink > > __ext4_unlink > > __ext4_mark_iloc_dirty > > if (sbi->s_journal == NULL) // s_journal is not set yet > > set_inode_metadata_writeback(inode); // sets I_METADATA_WRITEBACK > > iput(inode) > > iput_final(inode) > > ... > > writeback_single_inode > > __writeback_single_inode // since I_METADATA_WRITEBACK is set > > ... > > ext4_writepages > > ext4_writepages_down_read > > percpu_down_read(sbi->s_writepages_rwsem) > > <--- OOPS because this is initialized > > later in ext4_percpu_param_init() > > > > A simple fix seems to be to move ext4_percpu_param_init() call before > > ext4_load_journal() so that we can safely call ext4_writepages(). The > > below diff seems to be fixing the issue for me, does this look okay to > > you Jan? > > Thanks for report and the analysis! I didn't realize fastcommit replay > actually runs in nojournal mode. I don't think moving > ext4_percpu_param_init() is really correct - it initializes also directory, > free blocks and other counters and those depend on filesystem already being > in consistent state (i.e., after journal replay). We would have to move > just s_writepages_rwsem initialization. Hey Jan, yes right thanks for pointing that out. > > That being said I think a nicer fix is to just avoid setting > I_METADATA_WRITEBACK flag during fastcommit replay. We don't really need > it for anything during replay (it flushes the whole bdev anyway), it just > slows things down by more frequent buffer writeout. I've tested that change > and it fixes the problem for me. I'll post it officially shortly. Sure thanks! Regards, ojaswin > > Honza > > > Also, venkat can you please help test this in your system: > > > > diff --git a/fs/ext4/super.c b/fs/ext4/super.c > > index 2877a6cf6d09..6e05f191542c 100644 > > --- a/fs/ext4/super.c > > +++ b/fs/ext4/super.c > > @@ -5511,6 +5511,10 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb) > > goto failed_mount3a; > > } > > > > + err = ext4_percpu_param_init(sbi); > > + if (err) > > + goto failed_mount3a; > > + > > err = -EINVAL; > > /* > > * The first inode we look at is the journal inode. Don't try > > @@ -5659,10 +5663,6 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb) > > clear_opt2(sb, MB_OPTIMIZE_SCAN); > > } > > > > - err = ext4_percpu_param_init(sbi); > > - if (err) > > - goto failed_mount5; > > - > > err = ext4_mb_init(sb); > > if (err) { > > ext4_msg(sb, KERN_ERR, "failed to initialize mballoc (%d)", > > @@ -5764,7 +5764,6 @@ failed_mount8: __maybe_unused > > ext4_mb_release(sb); > > ext4_flex_groups_free(sbi); > > failed_mount5: > > - ext4_percpu_param_destroy(sbi); > > ext4_ext_release(sb); > > ext4_release_system_zone(sb); > > failed_mount4a: > > @@ -5785,6 +5784,7 @@ failed_mount8: __maybe_unused > > ext4_journal_destroy(sbi, sbi->s_journal); > > } > > failed_mount3a: > > + ext4_percpu_param_destroy(sbi); > > ext4_es_unregister_shrinker(sbi); > > failed_mount3: > > /* flush s_sb_upd_work before sbi destroy */ > > > > [1] https://lore.kernel.org/linux-ext4/20260727104923.3828017-37-jack@suse.cz/ > > > > > > > > > > > > Thanks, > > > > Venkat. > > > > > -- > Jan Kara <jack@suse.com> > SUSE Labs, CR ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-08-04 11:49 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-08-03 4:47 [BUG] ext4: NULL/invalid pointer dereference in ext4_writepages() during generic/039 Venkat Rao Bagalkote 2026-08-03 6:52 ` Ojaswin Mujoo 2026-08-03 19:48 ` Ojaswin Mujoo 2026-08-04 10:41 ` Jan Kara 2026-08-04 11:48 ` Ojaswin Mujoo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox