* possible bug ?
@ 2012-09-19 14:44 Adrian Sandu
2012-09-19 15:13 ` Eric Sandeen
0 siblings, 1 reply; 21+ messages in thread
From: Adrian Sandu @ 2012-09-19 14:44 UTC (permalink / raw)
To: linux-ext4
Hi people,
While trying to delete a couple of files today, I got into this lil'
thingy. It first happened in mc, then at a reboot.
[ 48.770178] IP: [<ffffffff811d6424>] ext4_ext_remove_space+0x9f4/0xe00
[ 48.770178] PGD 11d365067 PUD 11d1e8067 PMD 0
[ 48.770178] Oops: 0000 [#1] SMP
[ 48.770178] CPU 3
[ 48.770178] Modules linked in: ir_lirc_codec lirc_dev
ir_mce_kbd_decoder ir_sanyo_decoder ir_sony_decoder nvidia(PO)
ir_jvc_decoder ir_rc6_decoder rt2800usb rt2800lib crc_ccitt rt2x00usb
rt2x00lib ir_rc5_decoder snd_usb_audio ir_nec_decoder option
rc_rc6_mce nuvoton_cir rc_core snd_hwdep snd_usbmidi_lib snd_rawmidi
usb_wwan r8712u(C) usbserial
[ 48.770178]
[ 48.770178] Pid: 1465, comm: mount Tainted: P C O
3.4.9-gentoo #1 To Be Filled By O.E.M. To Be Filled By O.E.M./ION3D-HT
[ 48.922060] RIP: 0010:[<ffffffff811d6424>] [<ffffffff811d6424>]
ext4_ext_remove_space+0x9f4/0xe00
[ 48.922060] RSP: 0018:ffff88011a5b19d8 EFLAGS: 00010246
[ 48.922060] RAX: 0000000000000000 RBX: ffff88011d9c01b0 RCX: 0000000000000002
[ 48.922060] RDX: 0000000000000001 RSI: 0000000000000001 RDI: 000000000e590f51
[ 48.922060] RBP: ffff88011a5b1ae8 R08: 000000001d1bf000 R09: ffff88011d9c0180
[ 48.922060] R10: ffffffff811d5ddc R11: 0000000000000001 R12: 0000000000000000
[ 48.922060] R13: ffff88011bab9550 R14: 0000000000000000 R15: 0000000000000001
[ 48.922060] FS: 00007f0a3714d740(0000) GS:ffff880123d80000(0000)
knlGS:0000000000000000
[ 48.922060] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 48.922060] CR2: 0000000000000028 CR3: 000000011b704000 CR4: 00000000000007e0
[ 48.922060] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 48.922060] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 48.922060] Process mount (pid: 1465, threadinfo ffff88011a5b0000,
task ffff88011b417000)
[ 48.922060] Stack:
[ 48.922060] 0000000000001111 ffff88011bab9550 ffff88011bab94a0
ffff88011a5b1a98
[ 48.922060] ffff88011ae16e00 ffff880116f37a28 ffffffff1a5b1a68
ffff88011a4b8000
[ 48.922060] 000000011ec37000 0000000000000000 ffff88011bab94a0
ffff88011daf3c00
[ 48.922060] Call Trace:
[ 48.922060] [<ffffffff811d8953>] ext4_ext_truncate+0x1b3/0x1f0
[ 48.922060] [<ffffffff811cb1ec>] ? ext4_journal_start_sb+0x7c/0x1b0
[ 48.922060] [<ffffffff811ac878>] ext4_truncate+0xb8/0xf0
[ 48.922060] [<ffffffff811b13f0>] ext4_evict_inode+0x3a0/0x4a0
[ 48.922060] [<ffffffff8112f3d7>] evict+0xa7/0x1b0
[ 48.922060] [<ffffffff8112f5eb>] iput+0x10b/0x210
[ 48.922060] [<ffffffff811cf367>] ext4_fill_super+0x28f7/0x2a40
[ 48.922060] [<ffffffff810dcabe>] ? register_shrinker+0x4e/0x60
[ 48.922060] [<ffffffff811192f2>] mount_bdev+0x1a2/0x1e0
[ 48.922060] [<ffffffff811cca70>] ? ext4_calculate_overhead+0x3c0/0x3c0
[ 48.922060] [<ffffffff81112424>] ? __kmalloc_track_caller+0x54/0x160
[ 48.922060] [<ffffffff811c3cd0>] ext4_mount+0x10/0x20
[ 48.922060] [<ffffffff8111a073>] mount_fs+0x43/0x1c0
[ 48.922060] [<ffffffff810ebe2b>] ? __alloc_percpu+0xb/0x10
[ 48.922060] [<ffffffff81132baa>] vfs_kern_mount+0x6a/0x100
[ 48.922060] [<ffffffff81133400>] do_kern_mount+0x50/0x100
[ 48.922060] [<ffffffff81135020>] do_mount+0x520/0x7f0
[ 48.922060] [<ffffffff810e6e77>] ? memdup_user+0x47/0x90
[ 48.922060] [<ffffffff810e6f13>] ? strndup_user+0x53/0x70
[ 48.922060] [<ffffffff81135420>] sys_mount+0x90/0xe0
[ 48.922060] [<ffffffff815e43a2>] system_call_fastpath+0x16/0x1b
[ 48.922060] Code: 8d 04 40 48 8d 04 81 48 89 43 18 0f b7 49 02 48
83 c1 01 48 85 c0 48 89 0b 0f 85 c8 f8 ff ff 0f 0b 66 0f 1f 44 00 00
48 8b 43 28 <48> 8b 40 28 48 89 43 20 e9 91 f8 ff ff 0f 1f 80 00 00 00
00 44
[ 48.922060] RIP [<ffffffff811d6424>] ext4_ext_remove_space+0x9f4/0xe00
[ 48.922060] RSP <ffff88011a5b19d8>
[ 48.922060] CR2: 0000000000000028
[ 48.922862] ---[ end trace d17fa9fb727ed36f ]---
Any ideas ? I'm updating to 3.5.4 ( latest in gentoo's ~amd64 )
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: possible bug ?
2012-09-19 14:44 possible bug ? Adrian Sandu
@ 2012-09-19 15:13 ` Eric Sandeen
2012-09-19 16:09 ` Dmitry Monakhov
2012-09-19 16:26 ` Theodore Ts'o
0 siblings, 2 replies; 21+ messages in thread
From: Eric Sandeen @ 2012-09-19 15:13 UTC (permalink / raw)
To: Adrian Sandu; +Cc: linux-ext4
On 9/19/12 9:44 AM, Adrian Sandu wrote:
> Hi people,
>
> While trying to delete a couple of files today, I got into this lil'
> thingy. It first happened in mc, then at a reboot.
Did you cut off a few lines before this? Like one that said NULL pointer
dereference, or BUG() at .... or something similar?
I think we have a few reports of this in the fedora bugzilla, I don't
think we've gotten to the bottom of it yet.
-Eric
> [ 48.770178] IP: [<ffffffff811d6424>] ext4_ext_remove_space+0x9f4/0xe00
> [ 48.770178] PGD 11d365067 PUD 11d1e8067 PMD 0
> [ 48.770178] Oops: 0000 [#1] SMP
> [ 48.770178] CPU 3
> [ 48.770178] Modules linked in: ir_lirc_codec lirc_dev
> ir_mce_kbd_decoder ir_sanyo_decoder ir_sony_decoder nvidia(PO)
> ir_jvc_decoder ir_rc6_decoder rt2800usb rt2800lib crc_ccitt rt2x00usb
> rt2x00lib ir_rc5_decoder snd_usb_audio ir_nec_decoder option
> rc_rc6_mce nuvoton_cir rc_core snd_hwdep snd_usbmidi_lib snd_rawmidi
> usb_wwan r8712u(C) usbserial
> [ 48.770178]
> [ 48.770178] Pid: 1465, comm: mount Tainted: P C O
> 3.4.9-gentoo #1 To Be Filled By O.E.M. To Be Filled By O.E.M./ION3D-HT
> [ 48.922060] RIP: 0010:[<ffffffff811d6424>] [<ffffffff811d6424>]
> ext4_ext_remove_space+0x9f4/0xe00
> [ 48.922060] RSP: 0018:ffff88011a5b19d8 EFLAGS: 00010246
> [ 48.922060] RAX: 0000000000000000 RBX: ffff88011d9c01b0 RCX: 0000000000000002
> [ 48.922060] RDX: 0000000000000001 RSI: 0000000000000001 RDI: 000000000e590f51
> [ 48.922060] RBP: ffff88011a5b1ae8 R08: 000000001d1bf000 R09: ffff88011d9c0180
> [ 48.922060] R10: ffffffff811d5ddc R11: 0000000000000001 R12: 0000000000000000
> [ 48.922060] R13: ffff88011bab9550 R14: 0000000000000000 R15: 0000000000000001
> [ 48.922060] FS: 00007f0a3714d740(0000) GS:ffff880123d80000(0000)
> knlGS:0000000000000000
> [ 48.922060] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 48.922060] CR2: 0000000000000028 CR3: 000000011b704000 CR4: 00000000000007e0
> [ 48.922060] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 48.922060] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 48.922060] Process mount (pid: 1465, threadinfo ffff88011a5b0000,
> task ffff88011b417000)
> [ 48.922060] Stack:
> [ 48.922060] 0000000000001111 ffff88011bab9550 ffff88011bab94a0
> ffff88011a5b1a98
> [ 48.922060] ffff88011ae16e00 ffff880116f37a28 ffffffff1a5b1a68
> ffff88011a4b8000
> [ 48.922060] 000000011ec37000 0000000000000000 ffff88011bab94a0
> ffff88011daf3c00
> [ 48.922060] Call Trace:
> [ 48.922060] [<ffffffff811d8953>] ext4_ext_truncate+0x1b3/0x1f0
> [ 48.922060] [<ffffffff811cb1ec>] ? ext4_journal_start_sb+0x7c/0x1b0
> [ 48.922060] [<ffffffff811ac878>] ext4_truncate+0xb8/0xf0
> [ 48.922060] [<ffffffff811b13f0>] ext4_evict_inode+0x3a0/0x4a0
> [ 48.922060] [<ffffffff8112f3d7>] evict+0xa7/0x1b0
> [ 48.922060] [<ffffffff8112f5eb>] iput+0x10b/0x210
> [ 48.922060] [<ffffffff811cf367>] ext4_fill_super+0x28f7/0x2a40
> [ 48.922060] [<ffffffff810dcabe>] ? register_shrinker+0x4e/0x60
> [ 48.922060] [<ffffffff811192f2>] mount_bdev+0x1a2/0x1e0
> [ 48.922060] [<ffffffff811cca70>] ? ext4_calculate_overhead+0x3c0/0x3c0
> [ 48.922060] [<ffffffff81112424>] ? __kmalloc_track_caller+0x54/0x160
> [ 48.922060] [<ffffffff811c3cd0>] ext4_mount+0x10/0x20
> [ 48.922060] [<ffffffff8111a073>] mount_fs+0x43/0x1c0
> [ 48.922060] [<ffffffff810ebe2b>] ? __alloc_percpu+0xb/0x10
> [ 48.922060] [<ffffffff81132baa>] vfs_kern_mount+0x6a/0x100
> [ 48.922060] [<ffffffff81133400>] do_kern_mount+0x50/0x100
> [ 48.922060] [<ffffffff81135020>] do_mount+0x520/0x7f0
> [ 48.922060] [<ffffffff810e6e77>] ? memdup_user+0x47/0x90
> [ 48.922060] [<ffffffff810e6f13>] ? strndup_user+0x53/0x70
> [ 48.922060] [<ffffffff81135420>] sys_mount+0x90/0xe0
> [ 48.922060] [<ffffffff815e43a2>] system_call_fastpath+0x16/0x1b
> [ 48.922060] Code: 8d 04 40 48 8d 04 81 48 89 43 18 0f b7 49 02 48
> 83 c1 01 48 85 c0 48 89 0b 0f 85 c8 f8 ff ff 0f 0b 66 0f 1f 44 00 00
> 48 8b 43 28 <48> 8b 40 28 48 89 43 20 e9 91 f8 ff ff 0f 1f 80 00 00 00
> 00 44
> [ 48.922060] RIP [<ffffffff811d6424>] ext4_ext_remove_space+0x9f4/0xe00
> [ 48.922060] RSP <ffff88011a5b19d8>
> [ 48.922060] CR2: 0000000000000028
> [ 48.922862] ---[ end trace d17fa9fb727ed36f ]---
>
> Any ideas ? I'm updating to 3.5.4 ( latest in gentoo's ~amd64 )
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: possible bug ?
2012-09-19 15:13 ` Eric Sandeen
@ 2012-09-19 16:09 ` Dmitry Monakhov
2012-09-19 16:26 ` Theodore Ts'o
1 sibling, 0 replies; 21+ messages in thread
From: Dmitry Monakhov @ 2012-09-19 16:09 UTC (permalink / raw)
To: Eric Sandeen, Adrian Sandu; +Cc: linux-ext4
On Wed, 19 Sep 2012 10:13:46 -0500, Eric Sandeen <sandeen@redhat.com> wrote:
> On 9/19/12 9:44 AM, Adrian Sandu wrote:
> > Hi people,
> >
> > While trying to delete a couple of files today, I got into this lil'
> > thingy. It first happened in mc, then at a reboot.
>
> Did you cut off a few lines before this? Like one that said NULL pointer
> dereference, or BUG() at .... or something similar?
>
> I think we have a few reports of this in the fedora bugzilla, I don't
> think we've gotten to the bottom of it yet.
https://bugzilla.kernel.org/show_bug.cgi?id=47611
Patch available, linus already pull it
>
> -Eric
>
> > [ 48.770178] IP: [<ffffffff811d6424>] ext4_ext_remove_space+0x9f4/0xe00
> > [ 48.770178] PGD 11d365067 PUD 11d1e8067 PMD 0
> > [ 48.770178] Oops: 0000 [#1] SMP
> > [ 48.770178] CPU 3
> > [ 48.770178] Modules linked in: ir_lirc_codec lirc_dev
> > ir_mce_kbd_decoder ir_sanyo_decoder ir_sony_decoder nvidia(PO)
> > ir_jvc_decoder ir_rc6_decoder rt2800usb rt2800lib crc_ccitt rt2x00usb
> > rt2x00lib ir_rc5_decoder snd_usb_audio ir_nec_decoder option
> > rc_rc6_mce nuvoton_cir rc_core snd_hwdep snd_usbmidi_lib snd_rawmidi
> > usb_wwan r8712u(C) usbserial
> > [ 48.770178]
> > [ 48.770178] Pid: 1465, comm: mount Tainted: P C O
> > 3.4.9-gentoo #1 To Be Filled By O.E.M. To Be Filled By O.E.M./ION3D-HT
> > [ 48.922060] RIP: 0010:[<ffffffff811d6424>] [<ffffffff811d6424>]
> > ext4_ext_remove_space+0x9f4/0xe00
> > [ 48.922060] RSP: 0018:ffff88011a5b19d8 EFLAGS: 00010246
> > [ 48.922060] RAX: 0000000000000000 RBX: ffff88011d9c01b0 RCX: 0000000000000002
> > [ 48.922060] RDX: 0000000000000001 RSI: 0000000000000001 RDI: 000000000e590f51
> > [ 48.922060] RBP: ffff88011a5b1ae8 R08: 000000001d1bf000 R09: ffff88011d9c0180
> > [ 48.922060] R10: ffffffff811d5ddc R11: 0000000000000001 R12: 0000000000000000
> > [ 48.922060] R13: ffff88011bab9550 R14: 0000000000000000 R15: 0000000000000001
> > [ 48.922060] FS: 00007f0a3714d740(0000) GS:ffff880123d80000(0000)
> > knlGS:0000000000000000
> > [ 48.922060] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 48.922060] CR2: 0000000000000028 CR3: 000000011b704000 CR4: 00000000000007e0
> > [ 48.922060] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 48.922060] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [ 48.922060] Process mount (pid: 1465, threadinfo ffff88011a5b0000,
> > task ffff88011b417000)
> > [ 48.922060] Stack:
> > [ 48.922060] 0000000000001111 ffff88011bab9550 ffff88011bab94a0
> > ffff88011a5b1a98
> > [ 48.922060] ffff88011ae16e00 ffff880116f37a28 ffffffff1a5b1a68
> > ffff88011a4b8000
> > [ 48.922060] 000000011ec37000 0000000000000000 ffff88011bab94a0
> > ffff88011daf3c00
> > [ 48.922060] Call Trace:
> > [ 48.922060] [<ffffffff811d8953>] ext4_ext_truncate+0x1b3/0x1f0
> > [ 48.922060] [<ffffffff811cb1ec>] ? ext4_journal_start_sb+0x7c/0x1b0
> > [ 48.922060] [<ffffffff811ac878>] ext4_truncate+0xb8/0xf0
> > [ 48.922060] [<ffffffff811b13f0>] ext4_evict_inode+0x3a0/0x4a0
> > [ 48.922060] [<ffffffff8112f3d7>] evict+0xa7/0x1b0
> > [ 48.922060] [<ffffffff8112f5eb>] iput+0x10b/0x210
> > [ 48.922060] [<ffffffff811cf367>] ext4_fill_super+0x28f7/0x2a40
> > [ 48.922060] [<ffffffff810dcabe>] ? register_shrinker+0x4e/0x60
> > [ 48.922060] [<ffffffff811192f2>] mount_bdev+0x1a2/0x1e0
> > [ 48.922060] [<ffffffff811cca70>] ? ext4_calculate_overhead+0x3c0/0x3c0
> > [ 48.922060] [<ffffffff81112424>] ? __kmalloc_track_caller+0x54/0x160
> > [ 48.922060] [<ffffffff811c3cd0>] ext4_mount+0x10/0x20
> > [ 48.922060] [<ffffffff8111a073>] mount_fs+0x43/0x1c0
> > [ 48.922060] [<ffffffff810ebe2b>] ? __alloc_percpu+0xb/0x10
> > [ 48.922060] [<ffffffff81132baa>] vfs_kern_mount+0x6a/0x100
> > [ 48.922060] [<ffffffff81133400>] do_kern_mount+0x50/0x100
> > [ 48.922060] [<ffffffff81135020>] do_mount+0x520/0x7f0
> > [ 48.922060] [<ffffffff810e6e77>] ? memdup_user+0x47/0x90
> > [ 48.922060] [<ffffffff810e6f13>] ? strndup_user+0x53/0x70
> > [ 48.922060] [<ffffffff81135420>] sys_mount+0x90/0xe0
> > [ 48.922060] [<ffffffff815e43a2>] system_call_fastpath+0x16/0x1b
> > [ 48.922060] Code: 8d 04 40 48 8d 04 81 48 89 43 18 0f b7 49 02 48
> > 83 c1 01 48 85 c0 48 89 0b 0f 85 c8 f8 ff ff 0f 0b 66 0f 1f 44 00 00
> > 48 8b 43 28 <48> 8b 40 28 48 89 43 20 e9 91 f8 ff ff 0f 1f 80 00 00 00
> > 00 44
> > [ 48.922060] RIP [<ffffffff811d6424>] ext4_ext_remove_space+0x9f4/0xe00
> > [ 48.922060] RSP <ffff88011a5b19d8>
> > [ 48.922060] CR2: 0000000000000028
> > [ 48.922862] ---[ end trace d17fa9fb727ed36f ]---
> >
> > Any ideas ? I'm updating to 3.5.4 ( latest in gentoo's ~amd64 )
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: possible bug ?
2012-09-19 15:13 ` Eric Sandeen
2012-09-19 16:09 ` Dmitry Monakhov
@ 2012-09-19 16:26 ` Theodore Ts'o
2012-09-19 16:30 ` Eric Sandeen
1 sibling, 1 reply; 21+ messages in thread
From: Theodore Ts'o @ 2012-09-19 16:26 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Adrian Sandu, linux-ext4
On Wed, Sep 19, 2012 at 10:13:46AM -0500, Eric Sandeen wrote:
> On 9/19/12 9:44 AM, Adrian Sandu wrote:
> > Hi people,
> >
> > While trying to delete a couple of files today, I got into this lil'
> > thingy. It first happened in mc, then at a reboot.
>
> Did you cut off a few lines before this? Like one that said NULL pointer
> dereference, or BUG() at .... or something similar?
>
> I think we have a few reports of this in the fedora bugzilla, I don't
> think we've gotten to the bottom of it yet.
The fix is in mainline, and backported to v3.5.3. If Fedora's kernel
hasn't been updated to v3.5.3, it would be great if you could
encourage an update to get pushed out.
Thanks,
- Ted
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: possible bug ?
2012-09-19 16:26 ` Theodore Ts'o
@ 2012-09-19 16:30 ` Eric Sandeen
2012-09-19 16:35 ` Eric Sandeen
0 siblings, 1 reply; 21+ messages in thread
From: Eric Sandeen @ 2012-09-19 16:30 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Adrian Sandu, linux-ext4
On 9/19/12 11:26 AM, Theodore Ts'o wrote:
> On Wed, Sep 19, 2012 at 10:13:46AM -0500, Eric Sandeen wrote:
>> On 9/19/12 9:44 AM, Adrian Sandu wrote:
>>> Hi people,
>>>
>>> While trying to delete a couple of files today, I got into this lil'
>>> thingy. It first happened in mc, then at a reboot.
>>
>> Did you cut off a few lines before this? Like one that said NULL pointer
>> dereference, or BUG() at .... or something similar?
>>
>> I think we have a few reports of this in the fedora bugzilla, I don't
>> think we've gotten to the bottom of it yet.
>
> The fix is in mainline, and backported to v3.5.3. If Fedora's kernel
> hasn't been updated to v3.5.3, it would be great if you could
> encourage an update to get pushed out.
Hm I thought we had a similar bug on 3.5.3 so didn't think
it was fixed. let me check ... Nope sorry, it was older.
Thanks for the info, sorry I had missed it.
-Eric
> Thanks,
>
> - Ted
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: possible bug ?
2012-09-19 16:30 ` Eric Sandeen
@ 2012-09-19 16:35 ` Eric Sandeen
2012-09-19 16:50 ` Theodore Ts'o
0 siblings, 1 reply; 21+ messages in thread
From: Eric Sandeen @ 2012-09-19 16:35 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Adrian Sandu, linux-ext4
On 9/19/12 11:30 AM, Eric Sandeen wrote:
> On 9/19/12 11:26 AM, Theodore Ts'o wrote:
>> On Wed, Sep 19, 2012 at 10:13:46AM -0500, Eric Sandeen wrote:
>>> On 9/19/12 9:44 AM, Adrian Sandu wrote:
>>>> Hi people,
>>>>
>>>> While trying to delete a couple of files today, I got into this lil'
>>>> thingy. It first happened in mc, then at a reboot.
>>>
>>> Did you cut off a few lines before this? Like one that said NULL pointer
>>> dereference, or BUG() at .... or something similar?
>>>
>>> I think we have a few reports of this in the fedora bugzilla, I don't
>>> think we've gotten to the bottom of it yet.
>>
>> The fix is in mainline, and backported to v3.5.3. If Fedora's kernel
>> hasn't been updated to v3.5.3, it would be great if you could
>> encourage an update to get pushed out.
>
> Hm I thought we had a similar bug on 3.5.3 so didn't think
> it was fixed. let me check ... Nope sorry, it was older.
>
> Thanks for the info, sorry I had missed it.
Actually argh, too many bugs. ;) I was thinking of
https://bugzilla.redhat.com/show_bug.cgi?id=857618
which has been reported a few times, and hits a BUG() in
1965 ext4_ext_put_in_cache(struct inode *inode, ext4_lblk_t block,
1966 __u32 len, ext4_fsblk_t start)
1967 {
1968 struct ext4_ext_cache *cex;
1969 BUG_ON(len == 0);
but that's not what this reporter sees, sorry for the noise.
(Lukas pointed at upstream commit 31d4f3a2f3c73f279ff96a7135d7202ef6833f12
to avoid the BUG_ON but we still don't know the root cause I think).
Anyway, now I'm OT for this thread.
-Eric
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: possible bug ?
2012-09-19 16:35 ` Eric Sandeen
@ 2012-09-19 16:50 ` Theodore Ts'o
0 siblings, 0 replies; 21+ messages in thread
From: Theodore Ts'o @ 2012-09-19 16:50 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Adrian Sandu, linux-ext4
On Wed, Sep 19, 2012 at 11:35:18AM -0500, Eric Sandeen wrote:
>
> Actually argh, too many bugs. ;) I was thinking of
> https://bugzilla.redhat.com/show_bug.cgi?id=857618
>
> (Lukas pointed at upstream commit 31d4f3a2f3c73f279ff96a7135d7202ef6833f12
> to avoid the BUG_ON but we still don't know the root cause I think).
>
> Anyway, now I'm OT for this thread.
It is OT, so I've updated the RH bugzilla with my comments.
The one thing I would add is that we haven't been able to trigger this
via xfstests, so the workload needed trigger this must be fairly
unique/unusual. (Which is why I suggested in the bugzilla update that
if someone sees this pattern of corruption, it would be very useful to
get the pathname of the inode in question, in the hopes that this
provides some hint as to what happened.)
- Ted
^ permalink raw reply [flat|nested] 21+ messages in thread
* Possible bug?
@ 2025-11-08 22:19 Jani Partanen
2025-11-10 13:49 ` Jani Nikula
0 siblings, 1 reply; 21+ messages in thread
From: Jani Partanen @ 2025-11-08 22:19 UTC (permalink / raw)
To: intel-xe
Hello, I just got Intel Arc B570. It seems to work fine but every boot I
get this in dmesg:
[ 342.865944] ------------[ cut here ]------------
[ 342.865950] UBSAN: array-index-out-of-bounds in
drivers/mtd/devices/mtd_intel_dg.c:750:15
[ 342.865954] index 0 is out of range for type '<unknown> [*]'
[ 342.865957] CPU: 6 UID: 0 PID: 6184 Comm: (udev-worker) Not tainted
6.17.7-300.fc43.x86_64 #1 PREEMPT(lazy)
[ 342.865961] Hardware name: ASUS System Product Name/ROG CROSSHAIR
VIII HERO (WI-FI), BIOS 5302 10/03/2025
[ 342.865963] Call Trace:
[ 342.865967] <TASK>
[ 342.865972] dump_stack_lvl+0x5d/0x80
[ 342.865979] ubsan_epilogue+0x5/0x2b
[ 342.865984] __ubsan_handle_out_of_bounds.cold+0x54/0x59
[ 342.865991] intel_dg_mtd_probe+0x21b/0x240 [mtd_intel_dg]
[ 342.865998] ? __pfx_intel_dg_mtd_probe+0x10/0x10 [mtd_intel_dg]
[ 342.866002] auxiliary_bus_probe+0x49/0x80
[ 342.866006] ? srso_return_thunk+0x5/0x5f
[ 342.866012] really_probe+0xde/0x340
[ 342.866015] ? pm_runtime_barrier+0x55/0x90
[ 342.866019] __driver_probe_device+0x78/0x140
[ 342.866022] driver_probe_device+0x1f/0xa0
[ 342.866025] ? __pfx___driver_attach+0x10/0x10
[ 342.866027] __driver_attach+0xcb/0x1e0
[ 342.866030] bus_for_each_dev+0x85/0xd0
[ 342.866036] bus_add_driver+0x12f/0x210
[ 342.866040] ? __pfx_intel_dg_mtd_driver_init+0x10/0x10 [mtd_intel_dg]
[ 342.866044] driver_register+0x75/0xe0
[ 342.866047] __auxiliary_driver_register+0x6e/0xd0
[ 342.866050] do_one_initcall+0x5b/0x300
[ 342.866058] do_init_module+0x84/0x280
[ 342.866063] init_module_from_file+0x8a/0xe0
[ 342.866071] idempotent_init_module+0x114/0x310
[ 342.866078] __x64_sys_finit_module+0x6d/0xd0
[ 342.866081] ? syscall_trace_enter+0x108/0x1d0
[ 342.866086] do_syscall_64+0x7e/0x250
[ 342.866090] ? srso_return_thunk+0x5/0x5f
[ 342.866092] ? switch_fpu_return+0x4e/0xd0
[ 342.866097] ? srso_return_thunk+0x5/0x5f
[ 342.866099] ? arch_exit_to_user_mode_prepare.isra.0+0x6a/0x80
[ 342.866102] ? srso_return_thunk+0x5/0x5f
[ 342.866105] ? do_syscall_64+0xb6/0x250
[ 342.866108] ? srso_return_thunk+0x5/0x5f
[ 342.866111] ? terminate_walk+0xef/0x100
[ 342.866115] ? srso_return_thunk+0x5/0x5f
[ 342.866118] ? path_openat+0x116/0x2a0
[ 342.866122] ? srso_return_thunk+0x5/0x5f
[ 342.866125] ? do_filp_open+0xd8/0x180
[ 342.866131] ? __pfx_page_put_link+0x10/0x10
[ 342.866137] ? srso_return_thunk+0x5/0x5f
[ 342.866141] ? srso_return_thunk+0x5/0x5f
[ 342.866144] ? do_sys_openat2+0xa2/0xe0
[ 342.866149] ? srso_return_thunk+0x5/0x5f
[ 342.866152] ? syscall_exit_work+0x143/0x1b0
[ 342.866155] ? srso_return_thunk+0x5/0x5f
[ 342.866157] ? do_syscall_64+0xb6/0x250
[ 342.866161] ? srso_return_thunk+0x5/0x5f
[ 342.866163] ? srso_return_thunk+0x5/0x5f
[ 342.866166] ? irqentry_exit_to_user_mode+0x2c/0x1c0
[ 342.866169] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 342.866172] RIP: 0033:0x7fc5052ff34d
[ 342.866187] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa
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 8b 0d 83 6a 0f 00 f7 d8 64 89 01 48
[ 342.866189] RSP: 002b:00007ffc546026d8 EFLAGS: 00000246 ORIG_RAX:
0000000000000139
[ 342.866193] RAX: ffffffffffffffda RBX: 0000557240396680 RCX:
00007fc5052ff34d
[ 342.866194] RDX: 0000000000000004 RSI: 00007fc5059d85e1 RDI:
0000000000000021
[ 342.866196] RBP: 00007ffc54602770 R08: 0000000000000000 R09:
00005572401f3fd0
[ 342.866197] R10: 0000000000000000 R11: 0000000000000246 R12:
00007fc5059d85e1
[ 342.866199] R13: 0000000000020000 R14: 0000557240210540 R15:
0000000000000000
[ 342.866205] </TASK>
[ 342.866207] ---[ end trace ]---
[ 342.866225] ------------[ cut here ]------------
[ 342.866226] UBSAN: array-index-out-of-bounds in
drivers/mtd/devices/mtd_intel_dg.c:751:15
[ 342.866229] index 0 is out of range for type '<unknown> [*]'
[ 342.866232] CPU: 6 UID: 0 PID: 6184 Comm: (udev-worker) Not tainted
6.17.7-300.fc43.x86_64 #1 PREEMPT(lazy)
[ 342.866234] Hardware name: ASUS System Product Name/ROG CROSSHAIR
VIII HERO (WI-FI), BIOS 5302 10/03/2025
[ 342.866236] Call Trace:
[ 342.866237] <TASK>
[ 342.866239] dump_stack_lvl+0x5d/0x80
[ 342.866242] ubsan_epilogue+0x5/0x2b
[ 342.866245] __ubsan_handle_out_of_bounds.cold+0x54/0x59
[ 342.866249] intel_dg_mtd_probe+0x1fa/0x240 [mtd_intel_dg]
[ 342.866254] ? __pfx_intel_dg_mtd_probe+0x10/0x10 [mtd_intel_dg]
[ 342.866258] auxiliary_bus_probe+0x49/0x80
[ 342.866261] ? srso_return_thunk+0x5/0x5f
[ 342.866264] really_probe+0xde/0x340
[ 342.866266] ? pm_runtime_barrier+0x55/0x90
[ 342.866269] __driver_probe_device+0x78/0x140
[ 342.866272] driver_probe_device+0x1f/0xa0
[ 342.866275] ? __pfx___driver_attach+0x10/0x10
[ 342.866277] __driver_attach+0xcb/0x1e0
[ 342.866280] bus_for_each_dev+0x85/0xd0
[ 342.866284] bus_add_driver+0x12f/0x210
[ 342.866289] ? __pfx_intel_dg_mtd_driver_init+0x10/0x10 [mtd_intel_dg]
[ 342.866292] driver_register+0x75/0xe0
[ 342.866295] __auxiliary_driver_register+0x6e/0xd0
[ 342.866298] do_one_initcall+0x5b/0x300
[ 342.866304] do_init_module+0x84/0x280
[ 342.866307] init_module_from_file+0x8a/0xe0
[ 342.866316] idempotent_init_module+0x114/0x310
[ 342.866322] __x64_sys_finit_module+0x6d/0xd0
[ 342.866325] ? syscall_trace_enter+0x108/0x1d0
[ 342.866329] do_syscall_64+0x7e/0x250
[ 342.866331] ? srso_return_thunk+0x5/0x5f
[ 342.866334] ? switch_fpu_return+0x4e/0xd0
[ 342.866337] ? srso_return_thunk+0x5/0x5f
[ 342.866340] ? arch_exit_to_user_mode_prepare.isra.0+0x6a/0x80
[ 342.866342] ? srso_return_thunk+0x5/0x5f
[ 342.866345] ? do_syscall_64+0xb6/0x250
[ 342.866348] ? srso_return_thunk+0x5/0x5f
[ 342.866350] ? terminate_walk+0xef/0x100
[ 342.866353] ? srso_return_thunk+0x5/0x5f
[ 342.866356] ? path_openat+0x116/0x2a0
[ 342.866360] ? srso_return_thunk+0x5/0x5f
[ 342.866363] ? do_filp_open+0xd8/0x180
[ 342.866369] ? __pfx_page_put_link+0x10/0x10
[ 342.866374] ? srso_return_thunk+0x5/0x5f
[ 342.866378] ? srso_return_thunk+0x5/0x5f
[ 342.866381] ? do_sys_openat2+0xa2/0xe0
[ 342.866385] ? srso_return_thunk+0x5/0x5f
[ 342.866388] ? syscall_exit_work+0x143/0x1b0
[ 342.866391] ? srso_return_thunk+0x5/0x5f
[ 342.866394] ? do_syscall_64+0xb6/0x250
[ 342.866397] ? srso_return_thunk+0x5/0x5f
[ 342.866399] ? srso_return_thunk+0x5/0x5f
[ 342.866402] ? irqentry_exit_to_user_mode+0x2c/0x1c0
[ 342.866405] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 342.866407] RIP: 0033:0x7fc5052ff34d
[ 342.866411] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa
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 8b 0d 83 6a 0f 00 f7 d8 64 89 01 48
[ 342.866413] RSP: 002b:00007ffc546026d8 EFLAGS: 00000246 ORIG_RAX:
0000000000000139
[ 342.866415] RAX: ffffffffffffffda RBX: 0000557240396680 RCX:
00007fc5052ff34d
[ 342.866416] RDX: 0000000000000004 RSI: 00007fc5059d85e1 RDI:
0000000000000021
[ 342.866418] RBP: 00007ffc54602770 R08: 0000000000000000 R09:
00005572401f3fd0
[ 342.866419] R10: 0000000000000000 R11: 0000000000000246 R12:
00007fc5059d85e1
[ 342.866420] R13: 0000000000020000 R14: 0000557240210540 R15:
0000000000000000
[ 342.866427] </TASK>
[ 342.866451] ---[ end trace ]---
I also double checked that it's not some config error in my end by
starting up Fedora 43 live enviroment what cave me this same error.
As far as I know its related to mtd and here is what I can see:
mtdinfo -a
Count of MTD devices: 4
Present MTD devices: mtd0, mtd1, mtd2, mtd3
Sysfs interface supported: yes
mtd0
Name: xe.nvm.3584.DESCRIPTOR
Type: dataflash
Eraseblock size: 4096 bytes, 4.0 KiB
Amount of eraseblocks: 1 (4096 bytes, 4.0 KiB)
Minimum input/output unit size: 1 byte
Sub-page size: 1 byte
Character device major/minor: 90:0
Bad blocks are allowed: false
Device is writable: false
mtd1
Name: xe.nvm.3584.GSC
Type: dataflash
Eraseblock size: 4096 bytes, 4.0 KiB
Amount of eraseblocks: 1357 (5558272 bytes, 5.3 MiB)
Minimum input/output unit size: 1 byte
Sub-page size: 1 byte
Character device major/minor: 90:2
Bad blocks are allowed: false
Device is writable: false
mtd2
Name: xe.nvm.3584.OptionROM
Type: dataflash
Eraseblock size: 4096 bytes, 4.0 KiB
Amount of eraseblocks: 512 (2097152 bytes, 2.0 MiB)
Minimum input/output unit size: 1 byte
Sub-page size: 1 byte
Character device major/minor: 90:4
Bad blocks are allowed: false
Device is writable: false
mtd3
Name: xe.nvm.3584.DAM
Type: dataflash
Eraseblock size: 4096 bytes, 4.0 KiB
Amount of eraseblocks: 16 (65536 bytes, 64.0 KiB)
Minimum input/output unit size: 1 byte
Sub-page size: 1 byte
Character device major/minor: 90:6
Bad blocks are allowed: false
Device is writable: false
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Possible bug?
2025-11-08 22:19 Possible bug? Jani Partanen
@ 2025-11-10 13:49 ` Jani Nikula
0 siblings, 0 replies; 21+ messages in thread
From: Jani Nikula @ 2025-11-10 13:49 UTC (permalink / raw)
To: Jani Partanen, intel-xe; +Cc: Alexander Usyskin, linux-mtd
On Sun, 09 Nov 2025, Jani Partanen <jiipee@sotapeli.fi> wrote:
> Hello, I just got Intel Arc B570. It seems to work fine but every boot I
> get this in dmesg:
>
> [ 342.865944] ------------[ cut here ]------------
> [ 342.865950] UBSAN: array-index-out-of-bounds in
> drivers/mtd/devices/mtd_intel_dg.c:750:15
> [ 342.865954] index 0 is out of range for type '<unknown> [*]'
Cc: Alexander and linux-mtd.
It's probably due to struct intel_dg_nvm regions[] member being
__counted_by(nregions) but regions[] is indexed before nregions has been
initialized.
BR,
Jani.
> [ 342.865957] CPU: 6 UID: 0 PID: 6184 Comm: (udev-worker) Not tainted
> 6.17.7-300.fc43.x86_64 #1 PREEMPT(lazy)
> [ 342.865961] Hardware name: ASUS System Product Name/ROG CROSSHAIR
> VIII HERO (WI-FI), BIOS 5302 10/03/2025
> [ 342.865963] Call Trace:
> [ 342.865967] <TASK>
> [ 342.865972] dump_stack_lvl+0x5d/0x80
> [ 342.865979] ubsan_epilogue+0x5/0x2b
> [ 342.865984] __ubsan_handle_out_of_bounds.cold+0x54/0x59
> [ 342.865991] intel_dg_mtd_probe+0x21b/0x240 [mtd_intel_dg]
> [ 342.865998] ? __pfx_intel_dg_mtd_probe+0x10/0x10 [mtd_intel_dg]
> [ 342.866002] auxiliary_bus_probe+0x49/0x80
> [ 342.866006] ? srso_return_thunk+0x5/0x5f
> [ 342.866012] really_probe+0xde/0x340
> [ 342.866015] ? pm_runtime_barrier+0x55/0x90
> [ 342.866019] __driver_probe_device+0x78/0x140
> [ 342.866022] driver_probe_device+0x1f/0xa0
> [ 342.866025] ? __pfx___driver_attach+0x10/0x10
> [ 342.866027] __driver_attach+0xcb/0x1e0
> [ 342.866030] bus_for_each_dev+0x85/0xd0
> [ 342.866036] bus_add_driver+0x12f/0x210
> [ 342.866040] ? __pfx_intel_dg_mtd_driver_init+0x10/0x10 [mtd_intel_dg]
> [ 342.866044] driver_register+0x75/0xe0
> [ 342.866047] __auxiliary_driver_register+0x6e/0xd0
> [ 342.866050] do_one_initcall+0x5b/0x300
> [ 342.866058] do_init_module+0x84/0x280
> [ 342.866063] init_module_from_file+0x8a/0xe0
> [ 342.866071] idempotent_init_module+0x114/0x310
> [ 342.866078] __x64_sys_finit_module+0x6d/0xd0
> [ 342.866081] ? syscall_trace_enter+0x108/0x1d0
> [ 342.866086] do_syscall_64+0x7e/0x250
> [ 342.866090] ? srso_return_thunk+0x5/0x5f
> [ 342.866092] ? switch_fpu_return+0x4e/0xd0
> [ 342.866097] ? srso_return_thunk+0x5/0x5f
> [ 342.866099] ? arch_exit_to_user_mode_prepare.isra.0+0x6a/0x80
> [ 342.866102] ? srso_return_thunk+0x5/0x5f
> [ 342.866105] ? do_syscall_64+0xb6/0x250
> [ 342.866108] ? srso_return_thunk+0x5/0x5f
> [ 342.866111] ? terminate_walk+0xef/0x100
> [ 342.866115] ? srso_return_thunk+0x5/0x5f
> [ 342.866118] ? path_openat+0x116/0x2a0
> [ 342.866122] ? srso_return_thunk+0x5/0x5f
> [ 342.866125] ? do_filp_open+0xd8/0x180
> [ 342.866131] ? __pfx_page_put_link+0x10/0x10
> [ 342.866137] ? srso_return_thunk+0x5/0x5f
> [ 342.866141] ? srso_return_thunk+0x5/0x5f
> [ 342.866144] ? do_sys_openat2+0xa2/0xe0
> [ 342.866149] ? srso_return_thunk+0x5/0x5f
> [ 342.866152] ? syscall_exit_work+0x143/0x1b0
> [ 342.866155] ? srso_return_thunk+0x5/0x5f
> [ 342.866157] ? do_syscall_64+0xb6/0x250
> [ 342.866161] ? srso_return_thunk+0x5/0x5f
> [ 342.866163] ? srso_return_thunk+0x5/0x5f
> [ 342.866166] ? irqentry_exit_to_user_mode+0x2c/0x1c0
> [ 342.866169] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 342.866172] RIP: 0033:0x7fc5052ff34d
> [ 342.866187] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa
> 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 8b 0d 83 6a 0f 00 f7 d8 64 89 01 48
> [ 342.866189] RSP: 002b:00007ffc546026d8 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000139
> [ 342.866193] RAX: ffffffffffffffda RBX: 0000557240396680 RCX:
> 00007fc5052ff34d
> [ 342.866194] RDX: 0000000000000004 RSI: 00007fc5059d85e1 RDI:
> 0000000000000021
> [ 342.866196] RBP: 00007ffc54602770 R08: 0000000000000000 R09:
> 00005572401f3fd0
> [ 342.866197] R10: 0000000000000000 R11: 0000000000000246 R12:
> 00007fc5059d85e1
> [ 342.866199] R13: 0000000000020000 R14: 0000557240210540 R15:
> 0000000000000000
> [ 342.866205] </TASK>
> [ 342.866207] ---[ end trace ]---
> [ 342.866225] ------------[ cut here ]------------
> [ 342.866226] UBSAN: array-index-out-of-bounds in
> drivers/mtd/devices/mtd_intel_dg.c:751:15
> [ 342.866229] index 0 is out of range for type '<unknown> [*]'
> [ 342.866232] CPU: 6 UID: 0 PID: 6184 Comm: (udev-worker) Not tainted
> 6.17.7-300.fc43.x86_64 #1 PREEMPT(lazy)
> [ 342.866234] Hardware name: ASUS System Product Name/ROG CROSSHAIR
> VIII HERO (WI-FI), BIOS 5302 10/03/2025
> [ 342.866236] Call Trace:
> [ 342.866237] <TASK>
> [ 342.866239] dump_stack_lvl+0x5d/0x80
> [ 342.866242] ubsan_epilogue+0x5/0x2b
> [ 342.866245] __ubsan_handle_out_of_bounds.cold+0x54/0x59
> [ 342.866249] intel_dg_mtd_probe+0x1fa/0x240 [mtd_intel_dg]
> [ 342.866254] ? __pfx_intel_dg_mtd_probe+0x10/0x10 [mtd_intel_dg]
> [ 342.866258] auxiliary_bus_probe+0x49/0x80
> [ 342.866261] ? srso_return_thunk+0x5/0x5f
> [ 342.866264] really_probe+0xde/0x340
> [ 342.866266] ? pm_runtime_barrier+0x55/0x90
> [ 342.866269] __driver_probe_device+0x78/0x140
> [ 342.866272] driver_probe_device+0x1f/0xa0
> [ 342.866275] ? __pfx___driver_attach+0x10/0x10
> [ 342.866277] __driver_attach+0xcb/0x1e0
> [ 342.866280] bus_for_each_dev+0x85/0xd0
> [ 342.866284] bus_add_driver+0x12f/0x210
> [ 342.866289] ? __pfx_intel_dg_mtd_driver_init+0x10/0x10 [mtd_intel_dg]
> [ 342.866292] driver_register+0x75/0xe0
> [ 342.866295] __auxiliary_driver_register+0x6e/0xd0
> [ 342.866298] do_one_initcall+0x5b/0x300
> [ 342.866304] do_init_module+0x84/0x280
> [ 342.866307] init_module_from_file+0x8a/0xe0
> [ 342.866316] idempotent_init_module+0x114/0x310
> [ 342.866322] __x64_sys_finit_module+0x6d/0xd0
> [ 342.866325] ? syscall_trace_enter+0x108/0x1d0
> [ 342.866329] do_syscall_64+0x7e/0x250
> [ 342.866331] ? srso_return_thunk+0x5/0x5f
> [ 342.866334] ? switch_fpu_return+0x4e/0xd0
> [ 342.866337] ? srso_return_thunk+0x5/0x5f
> [ 342.866340] ? arch_exit_to_user_mode_prepare.isra.0+0x6a/0x80
> [ 342.866342] ? srso_return_thunk+0x5/0x5f
> [ 342.866345] ? do_syscall_64+0xb6/0x250
> [ 342.866348] ? srso_return_thunk+0x5/0x5f
> [ 342.866350] ? terminate_walk+0xef/0x100
> [ 342.866353] ? srso_return_thunk+0x5/0x5f
> [ 342.866356] ? path_openat+0x116/0x2a0
> [ 342.866360] ? srso_return_thunk+0x5/0x5f
> [ 342.866363] ? do_filp_open+0xd8/0x180
> [ 342.866369] ? __pfx_page_put_link+0x10/0x10
> [ 342.866374] ? srso_return_thunk+0x5/0x5f
> [ 342.866378] ? srso_return_thunk+0x5/0x5f
> [ 342.866381] ? do_sys_openat2+0xa2/0xe0
> [ 342.866385] ? srso_return_thunk+0x5/0x5f
> [ 342.866388] ? syscall_exit_work+0x143/0x1b0
> [ 342.866391] ? srso_return_thunk+0x5/0x5f
> [ 342.866394] ? do_syscall_64+0xb6/0x250
> [ 342.866397] ? srso_return_thunk+0x5/0x5f
> [ 342.866399] ? srso_return_thunk+0x5/0x5f
> [ 342.866402] ? irqentry_exit_to_user_mode+0x2c/0x1c0
> [ 342.866405] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 342.866407] RIP: 0033:0x7fc5052ff34d
> [ 342.866411] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa
> 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 8b 0d 83 6a 0f 00 f7 d8 64 89 01 48
> [ 342.866413] RSP: 002b:00007ffc546026d8 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000139
> [ 342.866415] RAX: ffffffffffffffda RBX: 0000557240396680 RCX:
> 00007fc5052ff34d
> [ 342.866416] RDX: 0000000000000004 RSI: 00007fc5059d85e1 RDI:
> 0000000000000021
> [ 342.866418] RBP: 00007ffc54602770 R08: 0000000000000000 R09:
> 00005572401f3fd0
> [ 342.866419] R10: 0000000000000000 R11: 0000000000000246 R12:
> 00007fc5059d85e1
> [ 342.866420] R13: 0000000000020000 R14: 0000557240210540 R15:
> 0000000000000000
> [ 342.866427] </TASK>
> [ 342.866451] ---[ end trace ]---
>
>
> I also double checked that it's not some config error in my end by
> starting up Fedora 43 live enviroment what cave me this same error.
>
> As far as I know its related to mtd and here is what I can see:
>
> mtdinfo -a
> Count of MTD devices: 4
> Present MTD devices: mtd0, mtd1, mtd2, mtd3
> Sysfs interface supported: yes
>
> mtd0
> Name: xe.nvm.3584.DESCRIPTOR
> Type: dataflash
> Eraseblock size: 4096 bytes, 4.0 KiB
> Amount of eraseblocks: 1 (4096 bytes, 4.0 KiB)
> Minimum input/output unit size: 1 byte
> Sub-page size: 1 byte
> Character device major/minor: 90:0
> Bad blocks are allowed: false
> Device is writable: false
>
> mtd1
> Name: xe.nvm.3584.GSC
> Type: dataflash
> Eraseblock size: 4096 bytes, 4.0 KiB
> Amount of eraseblocks: 1357 (5558272 bytes, 5.3 MiB)
> Minimum input/output unit size: 1 byte
> Sub-page size: 1 byte
> Character device major/minor: 90:2
> Bad blocks are allowed: false
> Device is writable: false
>
> mtd2
> Name: xe.nvm.3584.OptionROM
> Type: dataflash
> Eraseblock size: 4096 bytes, 4.0 KiB
> Amount of eraseblocks: 512 (2097152 bytes, 2.0 MiB)
> Minimum input/output unit size: 1 byte
> Sub-page size: 1 byte
> Character device major/minor: 90:4
> Bad blocks are allowed: false
> Device is writable: false
>
> mtd3
> Name: xe.nvm.3584.DAM
> Type: dataflash
> Eraseblock size: 4096 bytes, 4.0 KiB
> Amount of eraseblocks: 16 (65536 bytes, 64.0 KiB)
> Minimum input/output unit size: 1 byte
> Sub-page size: 1 byte
> Character device major/minor: 90:6
> Bad blocks are allowed: false
> Device is writable: false
>
--
Jani Nikula, Intel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Possible bug?
@ 2025-11-10 13:49 ` Jani Nikula
0 siblings, 0 replies; 21+ messages in thread
From: Jani Nikula @ 2025-11-10 13:49 UTC (permalink / raw)
To: Jani Partanen, intel-xe; +Cc: Alexander Usyskin, linux-mtd
On Sun, 09 Nov 2025, Jani Partanen <jiipee@sotapeli.fi> wrote:
> Hello, I just got Intel Arc B570. It seems to work fine but every boot I
> get this in dmesg:
>
> [ 342.865944] ------------[ cut here ]------------
> [ 342.865950] UBSAN: array-index-out-of-bounds in
> drivers/mtd/devices/mtd_intel_dg.c:750:15
> [ 342.865954] index 0 is out of range for type '<unknown> [*]'
Cc: Alexander and linux-mtd.
It's probably due to struct intel_dg_nvm regions[] member being
__counted_by(nregions) but regions[] is indexed before nregions has been
initialized.
BR,
Jani.
> [ 342.865957] CPU: 6 UID: 0 PID: 6184 Comm: (udev-worker) Not tainted
> 6.17.7-300.fc43.x86_64 #1 PREEMPT(lazy)
> [ 342.865961] Hardware name: ASUS System Product Name/ROG CROSSHAIR
> VIII HERO (WI-FI), BIOS 5302 10/03/2025
> [ 342.865963] Call Trace:
> [ 342.865967] <TASK>
> [ 342.865972] dump_stack_lvl+0x5d/0x80
> [ 342.865979] ubsan_epilogue+0x5/0x2b
> [ 342.865984] __ubsan_handle_out_of_bounds.cold+0x54/0x59
> [ 342.865991] intel_dg_mtd_probe+0x21b/0x240 [mtd_intel_dg]
> [ 342.865998] ? __pfx_intel_dg_mtd_probe+0x10/0x10 [mtd_intel_dg]
> [ 342.866002] auxiliary_bus_probe+0x49/0x80
> [ 342.866006] ? srso_return_thunk+0x5/0x5f
> [ 342.866012] really_probe+0xde/0x340
> [ 342.866015] ? pm_runtime_barrier+0x55/0x90
> [ 342.866019] __driver_probe_device+0x78/0x140
> [ 342.866022] driver_probe_device+0x1f/0xa0
> [ 342.866025] ? __pfx___driver_attach+0x10/0x10
> [ 342.866027] __driver_attach+0xcb/0x1e0
> [ 342.866030] bus_for_each_dev+0x85/0xd0
> [ 342.866036] bus_add_driver+0x12f/0x210
> [ 342.866040] ? __pfx_intel_dg_mtd_driver_init+0x10/0x10 [mtd_intel_dg]
> [ 342.866044] driver_register+0x75/0xe0
> [ 342.866047] __auxiliary_driver_register+0x6e/0xd0
> [ 342.866050] do_one_initcall+0x5b/0x300
> [ 342.866058] do_init_module+0x84/0x280
> [ 342.866063] init_module_from_file+0x8a/0xe0
> [ 342.866071] idempotent_init_module+0x114/0x310
> [ 342.866078] __x64_sys_finit_module+0x6d/0xd0
> [ 342.866081] ? syscall_trace_enter+0x108/0x1d0
> [ 342.866086] do_syscall_64+0x7e/0x250
> [ 342.866090] ? srso_return_thunk+0x5/0x5f
> [ 342.866092] ? switch_fpu_return+0x4e/0xd0
> [ 342.866097] ? srso_return_thunk+0x5/0x5f
> [ 342.866099] ? arch_exit_to_user_mode_prepare.isra.0+0x6a/0x80
> [ 342.866102] ? srso_return_thunk+0x5/0x5f
> [ 342.866105] ? do_syscall_64+0xb6/0x250
> [ 342.866108] ? srso_return_thunk+0x5/0x5f
> [ 342.866111] ? terminate_walk+0xef/0x100
> [ 342.866115] ? srso_return_thunk+0x5/0x5f
> [ 342.866118] ? path_openat+0x116/0x2a0
> [ 342.866122] ? srso_return_thunk+0x5/0x5f
> [ 342.866125] ? do_filp_open+0xd8/0x180
> [ 342.866131] ? __pfx_page_put_link+0x10/0x10
> [ 342.866137] ? srso_return_thunk+0x5/0x5f
> [ 342.866141] ? srso_return_thunk+0x5/0x5f
> [ 342.866144] ? do_sys_openat2+0xa2/0xe0
> [ 342.866149] ? srso_return_thunk+0x5/0x5f
> [ 342.866152] ? syscall_exit_work+0x143/0x1b0
> [ 342.866155] ? srso_return_thunk+0x5/0x5f
> [ 342.866157] ? do_syscall_64+0xb6/0x250
> [ 342.866161] ? srso_return_thunk+0x5/0x5f
> [ 342.866163] ? srso_return_thunk+0x5/0x5f
> [ 342.866166] ? irqentry_exit_to_user_mode+0x2c/0x1c0
> [ 342.866169] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 342.866172] RIP: 0033:0x7fc5052ff34d
> [ 342.866187] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa
> 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 8b 0d 83 6a 0f 00 f7 d8 64 89 01 48
> [ 342.866189] RSP: 002b:00007ffc546026d8 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000139
> [ 342.866193] RAX: ffffffffffffffda RBX: 0000557240396680 RCX:
> 00007fc5052ff34d
> [ 342.866194] RDX: 0000000000000004 RSI: 00007fc5059d85e1 RDI:
> 0000000000000021
> [ 342.866196] RBP: 00007ffc54602770 R08: 0000000000000000 R09:
> 00005572401f3fd0
> [ 342.866197] R10: 0000000000000000 R11: 0000000000000246 R12:
> 00007fc5059d85e1
> [ 342.866199] R13: 0000000000020000 R14: 0000557240210540 R15:
> 0000000000000000
> [ 342.866205] </TASK>
> [ 342.866207] ---[ end trace ]---
> [ 342.866225] ------------[ cut here ]------------
> [ 342.866226] UBSAN: array-index-out-of-bounds in
> drivers/mtd/devices/mtd_intel_dg.c:751:15
> [ 342.866229] index 0 is out of range for type '<unknown> [*]'
> [ 342.866232] CPU: 6 UID: 0 PID: 6184 Comm: (udev-worker) Not tainted
> 6.17.7-300.fc43.x86_64 #1 PREEMPT(lazy)
> [ 342.866234] Hardware name: ASUS System Product Name/ROG CROSSHAIR
> VIII HERO (WI-FI), BIOS 5302 10/03/2025
> [ 342.866236] Call Trace:
> [ 342.866237] <TASK>
> [ 342.866239] dump_stack_lvl+0x5d/0x80
> [ 342.866242] ubsan_epilogue+0x5/0x2b
> [ 342.866245] __ubsan_handle_out_of_bounds.cold+0x54/0x59
> [ 342.866249] intel_dg_mtd_probe+0x1fa/0x240 [mtd_intel_dg]
> [ 342.866254] ? __pfx_intel_dg_mtd_probe+0x10/0x10 [mtd_intel_dg]
> [ 342.866258] auxiliary_bus_probe+0x49/0x80
> [ 342.866261] ? srso_return_thunk+0x5/0x5f
> [ 342.866264] really_probe+0xde/0x340
> [ 342.866266] ? pm_runtime_barrier+0x55/0x90
> [ 342.866269] __driver_probe_device+0x78/0x140
> [ 342.866272] driver_probe_device+0x1f/0xa0
> [ 342.866275] ? __pfx___driver_attach+0x10/0x10
> [ 342.866277] __driver_attach+0xcb/0x1e0
> [ 342.866280] bus_for_each_dev+0x85/0xd0
> [ 342.866284] bus_add_driver+0x12f/0x210
> [ 342.866289] ? __pfx_intel_dg_mtd_driver_init+0x10/0x10 [mtd_intel_dg]
> [ 342.866292] driver_register+0x75/0xe0
> [ 342.866295] __auxiliary_driver_register+0x6e/0xd0
> [ 342.866298] do_one_initcall+0x5b/0x300
> [ 342.866304] do_init_module+0x84/0x280
> [ 342.866307] init_module_from_file+0x8a/0xe0
> [ 342.866316] idempotent_init_module+0x114/0x310
> [ 342.866322] __x64_sys_finit_module+0x6d/0xd0
> [ 342.866325] ? syscall_trace_enter+0x108/0x1d0
> [ 342.866329] do_syscall_64+0x7e/0x250
> [ 342.866331] ? srso_return_thunk+0x5/0x5f
> [ 342.866334] ? switch_fpu_return+0x4e/0xd0
> [ 342.866337] ? srso_return_thunk+0x5/0x5f
> [ 342.866340] ? arch_exit_to_user_mode_prepare.isra.0+0x6a/0x80
> [ 342.866342] ? srso_return_thunk+0x5/0x5f
> [ 342.866345] ? do_syscall_64+0xb6/0x250
> [ 342.866348] ? srso_return_thunk+0x5/0x5f
> [ 342.866350] ? terminate_walk+0xef/0x100
> [ 342.866353] ? srso_return_thunk+0x5/0x5f
> [ 342.866356] ? path_openat+0x116/0x2a0
> [ 342.866360] ? srso_return_thunk+0x5/0x5f
> [ 342.866363] ? do_filp_open+0xd8/0x180
> [ 342.866369] ? __pfx_page_put_link+0x10/0x10
> [ 342.866374] ? srso_return_thunk+0x5/0x5f
> [ 342.866378] ? srso_return_thunk+0x5/0x5f
> [ 342.866381] ? do_sys_openat2+0xa2/0xe0
> [ 342.866385] ? srso_return_thunk+0x5/0x5f
> [ 342.866388] ? syscall_exit_work+0x143/0x1b0
> [ 342.866391] ? srso_return_thunk+0x5/0x5f
> [ 342.866394] ? do_syscall_64+0xb6/0x250
> [ 342.866397] ? srso_return_thunk+0x5/0x5f
> [ 342.866399] ? srso_return_thunk+0x5/0x5f
> [ 342.866402] ? irqentry_exit_to_user_mode+0x2c/0x1c0
> [ 342.866405] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 342.866407] RIP: 0033:0x7fc5052ff34d
> [ 342.866411] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa
> 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 8b 0d 83 6a 0f 00 f7 d8 64 89 01 48
> [ 342.866413] RSP: 002b:00007ffc546026d8 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000139
> [ 342.866415] RAX: ffffffffffffffda RBX: 0000557240396680 RCX:
> 00007fc5052ff34d
> [ 342.866416] RDX: 0000000000000004 RSI: 00007fc5059d85e1 RDI:
> 0000000000000021
> [ 342.866418] RBP: 00007ffc54602770 R08: 0000000000000000 R09:
> 00005572401f3fd0
> [ 342.866419] R10: 0000000000000000 R11: 0000000000000246 R12:
> 00007fc5059d85e1
> [ 342.866420] R13: 0000000000020000 R14: 0000557240210540 R15:
> 0000000000000000
> [ 342.866427] </TASK>
> [ 342.866451] ---[ end trace ]---
>
>
> I also double checked that it's not some config error in my end by
> starting up Fedora 43 live enviroment what cave me this same error.
>
> As far as I know its related to mtd and here is what I can see:
>
> mtdinfo -a
> Count of MTD devices: 4
> Present MTD devices: mtd0, mtd1, mtd2, mtd3
> Sysfs interface supported: yes
>
> mtd0
> Name: xe.nvm.3584.DESCRIPTOR
> Type: dataflash
> Eraseblock size: 4096 bytes, 4.0 KiB
> Amount of eraseblocks: 1 (4096 bytes, 4.0 KiB)
> Minimum input/output unit size: 1 byte
> Sub-page size: 1 byte
> Character device major/minor: 90:0
> Bad blocks are allowed: false
> Device is writable: false
>
> mtd1
> Name: xe.nvm.3584.GSC
> Type: dataflash
> Eraseblock size: 4096 bytes, 4.0 KiB
> Amount of eraseblocks: 1357 (5558272 bytes, 5.3 MiB)
> Minimum input/output unit size: 1 byte
> Sub-page size: 1 byte
> Character device major/minor: 90:2
> Bad blocks are allowed: false
> Device is writable: false
>
> mtd2
> Name: xe.nvm.3584.OptionROM
> Type: dataflash
> Eraseblock size: 4096 bytes, 4.0 KiB
> Amount of eraseblocks: 512 (2097152 bytes, 2.0 MiB)
> Minimum input/output unit size: 1 byte
> Sub-page size: 1 byte
> Character device major/minor: 90:4
> Bad blocks are allowed: false
> Device is writable: false
>
> mtd3
> Name: xe.nvm.3584.DAM
> Type: dataflash
> Eraseblock size: 4096 bytes, 4.0 KiB
> Amount of eraseblocks: 16 (65536 bytes, 64.0 KiB)
> Minimum input/output unit size: 1 byte
> Sub-page size: 1 byte
> Character device major/minor: 90:6
> Bad blocks are allowed: false
> Device is writable: false
>
--
Jani Nikula, Intel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Possible bug?
2025-11-10 13:49 ` Jani Nikula
@ 2025-11-10 18:10 ` Lucas De Marchi
-1 siblings, 0 replies; 21+ messages in thread
From: Lucas De Marchi @ 2025-11-10 18:10 UTC (permalink / raw)
To: Jani Nikula; +Cc: Jani Partanen, intel-xe, Alexander Usyskin, linux-mtd
On Mon, Nov 10, 2025 at 03:49:20PM +0200, Jani Nikula wrote:
>On Sun, 09 Nov 2025, Jani Partanen <jiipee@sotapeli.fi> wrote:
>> Hello, I just got Intel Arc B570. It seems to work fine but every boot I
>> get this in dmesg:
>>
>> [ 342.865944] ------------[ cut here ]------------
>> [ 342.865950] UBSAN: array-index-out-of-bounds in
>> drivers/mtd/devices/mtd_intel_dg.c:750:15
>> [ 342.865954] index 0 is out of range for type '<unknown> [*]'
>
>Cc: Alexander and linux-mtd.
>
>It's probably due to struct intel_dg_nvm regions[] member being
>__counted_by(nregions) but regions[] is indexed before nregions has been
>initialized.
yeah... and we shouldn't silently continue hiding the ENOMEM... Sasha,
something like this?
Lucas De Marchi
----
diff --git a/drivers/mtd/devices/mtd_intel_dg.c b/drivers/mtd/devices/mtd_intel_dg.c
index b438ee5aacc34..114e69135b8d9 100644
--- a/drivers/mtd/devices/mtd_intel_dg.c
+++ b/drivers/mtd/devices/mtd_intel_dg.c
@@ -738,6 +738,7 @@ static int intel_dg_mtd_probe(struct auxiliary_device *aux_dev,
kref_init(&nvm->refcnt);
mutex_init(&nvm->lock);
+ nvm->nregions = nregions;
for (n = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
if (!invm->regions[i].name)
@@ -745,13 +746,15 @@ static int intel_dg_mtd_probe(struct auxiliary_device *aux_dev,
char *name = kasprintf(GFP_KERNEL, "%s.%s",
dev_name(&aux_dev->dev), invm->regions[i].name);
- if (!name)
- continue;
+ if (!name) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
nvm->regions[n].name = name;
nvm->regions[n].id = i;
n++;
}
- nvm->nregions = n; /* in case where kasprintf fail */
nvm->base = devm_ioremap_resource(device, &invm->bar);
if (IS_ERR(nvm->base)) {
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: Possible bug?
@ 2025-11-10 18:10 ` Lucas De Marchi
0 siblings, 0 replies; 21+ messages in thread
From: Lucas De Marchi @ 2025-11-10 18:10 UTC (permalink / raw)
To: Jani Nikula; +Cc: Jani Partanen, intel-xe, Alexander Usyskin, linux-mtd
On Mon, Nov 10, 2025 at 03:49:20PM +0200, Jani Nikula wrote:
>On Sun, 09 Nov 2025, Jani Partanen <jiipee@sotapeli.fi> wrote:
>> Hello, I just got Intel Arc B570. It seems to work fine but every boot I
>> get this in dmesg:
>>
>> [ 342.865944] ------------[ cut here ]------------
>> [ 342.865950] UBSAN: array-index-out-of-bounds in
>> drivers/mtd/devices/mtd_intel_dg.c:750:15
>> [ 342.865954] index 0 is out of range for type '<unknown> [*]'
>
>Cc: Alexander and linux-mtd.
>
>It's probably due to struct intel_dg_nvm regions[] member being
>__counted_by(nregions) but regions[] is indexed before nregions has been
>initialized.
yeah... and we shouldn't silently continue hiding the ENOMEM... Sasha,
something like this?
Lucas De Marchi
----
diff --git a/drivers/mtd/devices/mtd_intel_dg.c b/drivers/mtd/devices/mtd_intel_dg.c
index b438ee5aacc34..114e69135b8d9 100644
--- a/drivers/mtd/devices/mtd_intel_dg.c
+++ b/drivers/mtd/devices/mtd_intel_dg.c
@@ -738,6 +738,7 @@ static int intel_dg_mtd_probe(struct auxiliary_device *aux_dev,
kref_init(&nvm->refcnt);
mutex_init(&nvm->lock);
+ nvm->nregions = nregions;
for (n = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
if (!invm->regions[i].name)
@@ -745,13 +746,15 @@ static int intel_dg_mtd_probe(struct auxiliary_device *aux_dev,
char *name = kasprintf(GFP_KERNEL, "%s.%s",
dev_name(&aux_dev->dev), invm->regions[i].name);
- if (!name)
- continue;
+ if (!name) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
nvm->regions[n].name = name;
nvm->regions[n].id = i;
n++;
}
- nvm->nregions = n; /* in case where kasprintf fail */
nvm->base = devm_ioremap_resource(device, &invm->bar);
if (IS_ERR(nvm->base)) {
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 21+ messages in thread* RE: Possible bug?
2025-11-10 18:10 ` Lucas De Marchi
@ 2025-11-11 7:02 ` Usyskin, Alexander
-1 siblings, 0 replies; 21+ messages in thread
From: Usyskin, Alexander @ 2025-11-11 7:02 UTC (permalink / raw)
To: De Marchi, Lucas, Jani Nikula
Cc: Jani Partanen, intel-xe@lists.freedesktop.org,
linux-mtd@lists.infradead.org
> On Mon, Nov 10, 2025 at 03:49:20PM +0200, Jani Nikula wrote:
> >On Sun, 09 Nov 2025, Jani Partanen <jiipee@sotapeli.fi> wrote:
> >> Hello, I just got Intel Arc B570. It seems to work fine but every boot I
> >> get this in dmesg:
> >>
> >> [ 342.865944] ------------[ cut here ]------------
> >> [ 342.865950] UBSAN: array-index-out-of-bounds in
> >> drivers/mtd/devices/mtd_intel_dg.c:750:15
> >> [ 342.865954] index 0 is out of range for type '<unknown> [*]'
> >
> >Cc: Alexander and linux-mtd.
> >
> >It's probably due to struct intel_dg_nvm regions[] member being
> >__counted_by(nregions) but regions[] is indexed before nregions has been
> >initialized.
>
> yeah... and we shouldn't silently continue hiding the ENOMEM... Sasha,
> something like this?
>
In general, looks good for me, but I see that we can fill less entries because of
if (!invm->regions[i].name)
continue;
Let's leave 'nvm->nregions = n;' in place, only need to fix the comment.
- -
Thanks,
Sasha
> Lucas De Marchi
>
> ----
> diff --git a/drivers/mtd/devices/mtd_intel_dg.c
> b/drivers/mtd/devices/mtd_intel_dg.c
> index b438ee5aacc34..114e69135b8d9 100644
> --- a/drivers/mtd/devices/mtd_intel_dg.c
> +++ b/drivers/mtd/devices/mtd_intel_dg.c
> @@ -738,6 +738,7 @@ static int intel_dg_mtd_probe(struct auxiliary_device
> *aux_dev,
>
> kref_init(&nvm->refcnt);
> mutex_init(&nvm->lock);
> + nvm->nregions = nregions;
>
> for (n = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
> if (!invm->regions[i].name)
> @@ -745,13 +746,15 @@ static int intel_dg_mtd_probe(struct
> auxiliary_device *aux_dev,
>
> char *name = kasprintf(GFP_KERNEL, "%s.%s",
> dev_name(&aux_dev->dev), invm-
> >regions[i].name);
> - if (!name)
> - continue;
> + if (!name) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> nvm->regions[n].name = name;
> nvm->regions[n].id = i;
> n++;
> }
> - nvm->nregions = n; /* in case where kasprintf fail */
>
> nvm->base = devm_ioremap_resource(device, &invm->bar);
> if (IS_ERR(nvm->base)) {
^ permalink raw reply [flat|nested] 21+ messages in thread* RE: Possible bug?
@ 2025-11-11 7:02 ` Usyskin, Alexander
0 siblings, 0 replies; 21+ messages in thread
From: Usyskin, Alexander @ 2025-11-11 7:02 UTC (permalink / raw)
To: De Marchi, Lucas, Jani Nikula
Cc: Jani Partanen, intel-xe@lists.freedesktop.org,
linux-mtd@lists.infradead.org
> On Mon, Nov 10, 2025 at 03:49:20PM +0200, Jani Nikula wrote:
> >On Sun, 09 Nov 2025, Jani Partanen <jiipee@sotapeli.fi> wrote:
> >> Hello, I just got Intel Arc B570. It seems to work fine but every boot I
> >> get this in dmesg:
> >>
> >> [ 342.865944] ------------[ cut here ]------------
> >> [ 342.865950] UBSAN: array-index-out-of-bounds in
> >> drivers/mtd/devices/mtd_intel_dg.c:750:15
> >> [ 342.865954] index 0 is out of range for type '<unknown> [*]'
> >
> >Cc: Alexander and linux-mtd.
> >
> >It's probably due to struct intel_dg_nvm regions[] member being
> >__counted_by(nregions) but regions[] is indexed before nregions has been
> >initialized.
>
> yeah... and we shouldn't silently continue hiding the ENOMEM... Sasha,
> something like this?
>
In general, looks good for me, but I see that we can fill less entries because of
if (!invm->regions[i].name)
continue;
Let's leave 'nvm->nregions = n;' in place, only need to fix the comment.
- -
Thanks,
Sasha
> Lucas De Marchi
>
> ----
> diff --git a/drivers/mtd/devices/mtd_intel_dg.c
> b/drivers/mtd/devices/mtd_intel_dg.c
> index b438ee5aacc34..114e69135b8d9 100644
> --- a/drivers/mtd/devices/mtd_intel_dg.c
> +++ b/drivers/mtd/devices/mtd_intel_dg.c
> @@ -738,6 +738,7 @@ static int intel_dg_mtd_probe(struct auxiliary_device
> *aux_dev,
>
> kref_init(&nvm->refcnt);
> mutex_init(&nvm->lock);
> + nvm->nregions = nregions;
>
> for (n = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
> if (!invm->regions[i].name)
> @@ -745,13 +746,15 @@ static int intel_dg_mtd_probe(struct
> auxiliary_device *aux_dev,
>
> char *name = kasprintf(GFP_KERNEL, "%s.%s",
> dev_name(&aux_dev->dev), invm-
> >regions[i].name);
> - if (!name)
> - continue;
> + if (!name) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> nvm->regions[n].name = name;
> nvm->regions[n].id = i;
> n++;
> }
> - nvm->nregions = n; /* in case where kasprintf fail */
>
> nvm->base = devm_ioremap_resource(device, &invm->bar);
> if (IS_ERR(nvm->base)) {
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 21+ messages in thread* RE: Possible bug?
2025-11-11 7:02 ` Usyskin, Alexander
@ 2025-11-11 8:06 ` Jani Nikula
-1 siblings, 0 replies; 21+ messages in thread
From: Jani Nikula @ 2025-11-11 8:06 UTC (permalink / raw)
To: Usyskin, Alexander, De Marchi, Lucas
Cc: Jani Partanen, intel-xe@lists.freedesktop.org,
linux-mtd@lists.infradead.org
On Tue, 11 Nov 2025, "Usyskin, Alexander" <alexander.usyskin@intel.com> wrote:
>> On Mon, Nov 10, 2025 at 03:49:20PM +0200, Jani Nikula wrote:
>> >On Sun, 09 Nov 2025, Jani Partanen <jiipee@sotapeli.fi> wrote:
>> >> Hello, I just got Intel Arc B570. It seems to work fine but every boot I
>> >> get this in dmesg:
>> >>
>> >> [ 342.865944] ------------[ cut here ]------------
>> >> [ 342.865950] UBSAN: array-index-out-of-bounds in
>> >> drivers/mtd/devices/mtd_intel_dg.c:750:15
>> >> [ 342.865954] index 0 is out of range for type '<unknown> [*]'
>> >
>> >Cc: Alexander and linux-mtd.
>> >
>> >It's probably due to struct intel_dg_nvm regions[] member being
>> >__counted_by(nregions) but regions[] is indexed before nregions has been
>> >initialized.
>>
>> yeah... and we shouldn't silently continue hiding the ENOMEM... Sasha,
>> something like this?
>>
>
> In general, looks good for me, but I see that we can fill less entries because of
> if (!invm->regions[i].name)
> continue;
>
> Let's leave 'nvm->nregions = n;' in place, only need to fix the comment.
You have this in place, nregions already accouns for them:
/* count available regions */
for (nregions = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
if (invm->regions[i].name)
nregions++;
}
BR,
Jani.
>
> - -
> Thanks,
> Sasha
>
>> Lucas De Marchi
>>
>> ----
>> diff --git a/drivers/mtd/devices/mtd_intel_dg.c
>> b/drivers/mtd/devices/mtd_intel_dg.c
>> index b438ee5aacc34..114e69135b8d9 100644
>> --- a/drivers/mtd/devices/mtd_intel_dg.c
>> +++ b/drivers/mtd/devices/mtd_intel_dg.c
>> @@ -738,6 +738,7 @@ static int intel_dg_mtd_probe(struct auxiliary_device
>> *aux_dev,
>>
>> kref_init(&nvm->refcnt);
>> mutex_init(&nvm->lock);
>> + nvm->nregions = nregions;
>>
>> for (n = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
>> if (!invm->regions[i].name)
>> @@ -745,13 +746,15 @@ static int intel_dg_mtd_probe(struct
>> auxiliary_device *aux_dev,
>>
>> char *name = kasprintf(GFP_KERNEL, "%s.%s",
>> dev_name(&aux_dev->dev), invm-
>> >regions[i].name);
>> - if (!name)
>> - continue;
>> + if (!name) {
>> + ret = -ENOMEM;
>> + goto err;
>> + }
>> +
>> nvm->regions[n].name = name;
>> nvm->regions[n].id = i;
>> n++;
>> }
>> - nvm->nregions = n; /* in case where kasprintf fail */
>>
>> nvm->base = devm_ioremap_resource(device, &invm->bar);
>> if (IS_ERR(nvm->base)) {
--
Jani Nikula, Intel
^ permalink raw reply [flat|nested] 21+ messages in thread* RE: Possible bug?
@ 2025-11-11 8:06 ` Jani Nikula
0 siblings, 0 replies; 21+ messages in thread
From: Jani Nikula @ 2025-11-11 8:06 UTC (permalink / raw)
To: Usyskin, Alexander, De Marchi, Lucas
Cc: Jani Partanen, intel-xe@lists.freedesktop.org,
linux-mtd@lists.infradead.org
On Tue, 11 Nov 2025, "Usyskin, Alexander" <alexander.usyskin@intel.com> wrote:
>> On Mon, Nov 10, 2025 at 03:49:20PM +0200, Jani Nikula wrote:
>> >On Sun, 09 Nov 2025, Jani Partanen <jiipee@sotapeli.fi> wrote:
>> >> Hello, I just got Intel Arc B570. It seems to work fine but every boot I
>> >> get this in dmesg:
>> >>
>> >> [ 342.865944] ------------[ cut here ]------------
>> >> [ 342.865950] UBSAN: array-index-out-of-bounds in
>> >> drivers/mtd/devices/mtd_intel_dg.c:750:15
>> >> [ 342.865954] index 0 is out of range for type '<unknown> [*]'
>> >
>> >Cc: Alexander and linux-mtd.
>> >
>> >It's probably due to struct intel_dg_nvm regions[] member being
>> >__counted_by(nregions) but regions[] is indexed before nregions has been
>> >initialized.
>>
>> yeah... and we shouldn't silently continue hiding the ENOMEM... Sasha,
>> something like this?
>>
>
> In general, looks good for me, but I see that we can fill less entries because of
> if (!invm->regions[i].name)
> continue;
>
> Let's leave 'nvm->nregions = n;' in place, only need to fix the comment.
You have this in place, nregions already accouns for them:
/* count available regions */
for (nregions = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
if (invm->regions[i].name)
nregions++;
}
BR,
Jani.
>
> - -
> Thanks,
> Sasha
>
>> Lucas De Marchi
>>
>> ----
>> diff --git a/drivers/mtd/devices/mtd_intel_dg.c
>> b/drivers/mtd/devices/mtd_intel_dg.c
>> index b438ee5aacc34..114e69135b8d9 100644
>> --- a/drivers/mtd/devices/mtd_intel_dg.c
>> +++ b/drivers/mtd/devices/mtd_intel_dg.c
>> @@ -738,6 +738,7 @@ static int intel_dg_mtd_probe(struct auxiliary_device
>> *aux_dev,
>>
>> kref_init(&nvm->refcnt);
>> mutex_init(&nvm->lock);
>> + nvm->nregions = nregions;
>>
>> for (n = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
>> if (!invm->regions[i].name)
>> @@ -745,13 +746,15 @@ static int intel_dg_mtd_probe(struct
>> auxiliary_device *aux_dev,
>>
>> char *name = kasprintf(GFP_KERNEL, "%s.%s",
>> dev_name(&aux_dev->dev), invm-
>> >regions[i].name);
>> - if (!name)
>> - continue;
>> + if (!name) {
>> + ret = -ENOMEM;
>> + goto err;
>> + }
>> +
>> nvm->regions[n].name = name;
>> nvm->regions[n].id = i;
>> n++;
>> }
>> - nvm->nregions = n; /* in case where kasprintf fail */
>>
>> nvm->base = devm_ioremap_resource(device, &invm->bar);
>> if (IS_ERR(nvm->base)) {
--
Jani Nikula, Intel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 21+ messages in thread* RE: Possible bug?
2025-11-11 8:06 ` Jani Nikula
@ 2025-11-11 10:58 ` Usyskin, Alexander
-1 siblings, 0 replies; 21+ messages in thread
From: Usyskin, Alexander @ 2025-11-11 10:58 UTC (permalink / raw)
To: Jani Nikula, De Marchi, Lucas
Cc: Jani Partanen, intel-xe@lists.freedesktop.org,
linux-mtd@lists.infradead.org
> >> >
> >> >It's probably due to struct intel_dg_nvm regions[] member being
> >> >__counted_by(nregions) but regions[] is indexed before nregions has
> been
> >> >initialized.
> >>
> >> yeah... and we shouldn't silently continue hiding the ENOMEM... Sasha,
> >> something like this?
> >>
> >
> > In general, looks good for me, but I see that we can fill less entries because
> of
> > if (!invm->regions[i].name)
> > continue;
> >
> > Let's leave 'nvm->nregions = n;' in place, only need to fix the comment.
>
> You have this in place, nregions already accouns for them:
>
> /* count available regions */
> for (nregions = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
> if (invm->regions[i].name)
> nregions++;
> }
>
Yeah, missed this, so original fix from Lucas is ok
- -
Thanks,
Sasha
> BR,
> Jani.
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread* RE: Possible bug?
@ 2025-11-11 10:58 ` Usyskin, Alexander
0 siblings, 0 replies; 21+ messages in thread
From: Usyskin, Alexander @ 2025-11-11 10:58 UTC (permalink / raw)
To: Jani Nikula, De Marchi, Lucas
Cc: Jani Partanen, intel-xe@lists.freedesktop.org,
linux-mtd@lists.infradead.org
> >> >
> >> >It's probably due to struct intel_dg_nvm regions[] member being
> >> >__counted_by(nregions) but regions[] is indexed before nregions has
> been
> >> >initialized.
> >>
> >> yeah... and we shouldn't silently continue hiding the ENOMEM... Sasha,
> >> something like this?
> >>
> >
> > In general, looks good for me, but I see that we can fill less entries because
> of
> > if (!invm->regions[i].name)
> > continue;
> >
> > Let's leave 'nvm->nregions = n;' in place, only need to fix the comment.
>
> You have this in place, nregions already accouns for them:
>
> /* count available regions */
> for (nregions = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
> if (invm->regions[i].name)
> nregions++;
> }
>
Yeah, missed this, so original fix from Lucas is ok
- -
Thanks,
Sasha
> BR,
> Jani.
>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Possible bug?
2025-11-11 10:58 ` Usyskin, Alexander
@ 2025-11-12 14:57 ` Lucas De Marchi
-1 siblings, 0 replies; 21+ messages in thread
From: Lucas De Marchi @ 2025-11-12 14:57 UTC (permalink / raw)
To: Usyskin, Alexander
Cc: Jani Nikula, Jani Partanen, intel-xe@lists.freedesktop.org,
linux-mtd@lists.infradead.org
On Tue, Nov 11, 2025 at 10:58:03AM +0000, Usyskin, Alexander wrote:
>> >> >
>> >> >It's probably due to struct intel_dg_nvm regions[] member being
>> >> >__counted_by(nregions) but regions[] is indexed before nregions has
>> been
>> >> >initialized.
>> >>
>> >> yeah... and we shouldn't silently continue hiding the ENOMEM... Sasha,
>> >> something like this?
>> >>
>> >
>> > In general, looks good for me, but I see that we can fill less entries because
>> of
>> > if (!invm->regions[i].name)
>> > continue;
>> >
>> > Let's leave 'nvm->nregions = n;' in place, only need to fix the comment.
>>
>> You have this in place, nregions already accouns for them:
>>
>> /* count available regions */
>> for (nregions = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
>> if (invm->regions[i].name)
>> nregions++;
>> }
>>
>
>Yeah, missed this, so original fix from Lucas is ok
I submitted it as a proper patch with commit message:
https://lore.kernel.org/all/20251111-mtd-nregions-v1-1-61db61e78c63@intel.com/
Lucas De Marchi
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Possible bug?
@ 2025-11-12 14:57 ` Lucas De Marchi
0 siblings, 0 replies; 21+ messages in thread
From: Lucas De Marchi @ 2025-11-12 14:57 UTC (permalink / raw)
To: Usyskin, Alexander
Cc: Jani Nikula, Jani Partanen, intel-xe@lists.freedesktop.org,
linux-mtd@lists.infradead.org
On Tue, Nov 11, 2025 at 10:58:03AM +0000, Usyskin, Alexander wrote:
>> >> >
>> >> >It's probably due to struct intel_dg_nvm regions[] member being
>> >> >__counted_by(nregions) but regions[] is indexed before nregions has
>> been
>> >> >initialized.
>> >>
>> >> yeah... and we shouldn't silently continue hiding the ENOMEM... Sasha,
>> >> something like this?
>> >>
>> >
>> > In general, looks good for me, but I see that we can fill less entries because
>> of
>> > if (!invm->regions[i].name)
>> > continue;
>> >
>> > Let's leave 'nvm->nregions = n;' in place, only need to fix the comment.
>>
>> You have this in place, nregions already accouns for them:
>>
>> /* count available regions */
>> for (nregions = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
>> if (invm->regions[i].name)
>> nregions++;
>> }
>>
>
>Yeah, missed this, so original fix from Lucas is ok
I submitted it as a proper patch with commit message:
https://lore.kernel.org/all/20251111-mtd-nregions-v1-1-61db61e78c63@intel.com/
Lucas De Marchi
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Possible bug?
2025-11-12 14:57 ` Lucas De Marchi
(?)
@ 2025-11-14 16:22 ` Jani Partanen
-1 siblings, 0 replies; 21+ messages in thread
From: Jani Partanen @ 2025-11-14 16:22 UTC (permalink / raw)
To: Lucas De Marchi, Usyskin, Alexander
Cc: Jani Nikula, intel-xe@lists.freedesktop.org,
linux-mtd@lists.infradead.org
I was finally able to test this and its working.
Thanks for quick fix.
// Jani
On 12/11/2025 16.57, Lucas De Marchi wrote:
> On Tue, Nov 11, 2025 at 10:58:03AM +0000, Usyskin, Alexander wrote:
>>> >> >
>>> >> >It's probably due to struct intel_dg_nvm regions[] member being
>>> >> >__counted_by(nregions) but regions[] is indexed before nregions has
>>> been
>>> >> >initialized.
>>> >>
>>> >> yeah... and we shouldn't silently continue hiding the ENOMEM...
>>> Sasha,
>>> >> something like this?
>>> >>
>>> >
>>> > In general, looks good for me, but I see that we can fill less
>>> entries because
>>> of
>>> > if (!invm->regions[i].name)
>>> > continue;
>>> >
>>> > Let's leave 'nvm->nregions = n;' in place, only need to fix the
>>> comment.
>>>
>>> You have this in place, nregions already accouns for them:
>>>
>>> /* count available regions */
>>> for (nregions = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
>>> if (invm->regions[i].name)
>>> nregions++;
>>> }
>>>
>>
>> Yeah, missed this, so original fix from Lucas is ok
>
> I submitted it as a proper patch with commit message:
>
> https://lore.kernel.org/all/20251111-mtd-nregions-v1-1-61db61e78c63@intel.com/
>
>
> Lucas De Marchi
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2025-11-14 16:22 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-19 14:44 possible bug ? Adrian Sandu
2012-09-19 15:13 ` Eric Sandeen
2012-09-19 16:09 ` Dmitry Monakhov
2012-09-19 16:26 ` Theodore Ts'o
2012-09-19 16:30 ` Eric Sandeen
2012-09-19 16:35 ` Eric Sandeen
2012-09-19 16:50 ` Theodore Ts'o
-- strict thread matches above, loose matches on Subject: below --
2025-11-08 22:19 Possible bug? Jani Partanen
2025-11-10 13:49 ` Jani Nikula
2025-11-10 13:49 ` Jani Nikula
2025-11-10 18:10 ` Lucas De Marchi
2025-11-10 18:10 ` Lucas De Marchi
2025-11-11 7:02 ` Usyskin, Alexander
2025-11-11 7:02 ` Usyskin, Alexander
2025-11-11 8:06 ` Jani Nikula
2025-11-11 8:06 ` Jani Nikula
2025-11-11 10:58 ` Usyskin, Alexander
2025-11-11 10:58 ` Usyskin, Alexander
2025-11-12 14:57 ` Lucas De Marchi
2025-11-12 14:57 ` Lucas De Marchi
2025-11-14 16:22 ` Jani Partanen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.