* s390x: kernel BUG at fs/ext4/inode.c:1591! [not found] <863434221.7624846.1364452822093.JavaMail.root@redhat.com> @ 2013-03-28 6:40 ` CAI Qian 0 siblings, 0 replies; 42+ messages in thread From: CAI Qian @ 2013-03-28 6:40 UTC (permalink / raw) To: LKML; +Cc: linux-s390 , Steve Best, Theodore Ts'o, linux-ext4 System hung when running xfstests-dev 013 test case on an s390x guest. Never saw this on 3.9-rc3 before but need to double-check. Any idea? CAI Qian Ý 1113.795759¨ ------------Ý cut here ¨------------ Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! Ý 1113.795845¨ illegal operation: 0001 Ý#1¨ SMP Ý 1113.795848¨ Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipt able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defra g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tab les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod dasd_eck d_mod dasd_mod lcs ctcm qeth fsm qdio ccwgroup dm_mirror dm_region_hash dm_log d m_mod Ý 1113.795880¨ CPU: 1 Not tainted 3.9.0-rc4+ #2 Ý 1113.795882¨ Process flush-253:1 (pid: 12418, task: 0000000003f04890, ksp: 000 0000032eab3b8) Ý 1113.795885¨ Krnl PSW : 0704e00180000000 000000000030bc62 (mpage_da_submit_io+ 0x38e/0x3c0) Ý 1113.795895¨ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 EA: 3 Krnl GPRS: 0000000001000000 000000001b5823a8 0000000000000010 000000001b5823a8 Ý 1113.795900¨ 0000000000000000 00000000000000af 0000000000001000 000 0000032eab9c8 Ý 1113.795902¨ 000003d10053bb40 0000000032eaba30 00000000000000a1 000 0000032eaba98 Ý 1113.795905¨ 00000000000100b0 00000000000000a1 000000000030b9a8 000 0000032eab8a0 Ý 1113.795921¨ Krnl Code: 000000000030bc54: f0dca7f4fecf srp 2036(14, %r10),3791(%r15),12 MORE... ZVM-RHTS ================================================================================ 000000000030bc5a: a7f40001 brc 15,30bc5c #000000000030bc5e: a7f40001 brc 15,30bc60 >000000000030bc62: a7f40001 brc 15,30bc64 000000000030bc66: a7f40001 brc 15,30bc68 000000000030bc6a: 4120f0e8 la %r2,232(%r15) 000000000030bc6e: a7180000 lhi %r1,0 Ý 1113.796303¨ Call Trace: Ý 1113.796306¨ (Ý<000000000030b9a8>¨ mpage_da_submit_io+0xd4/0x3c0) Ý 1113.796311¨ Ý<000000000031204c>¨ mpage_da_map_and_submit+0x150/0x41c Ý 1113.796314¨ Ý<0000000000312bac>¨ ext4_da_writepages+0x364/0x628 Ý 1113.796317¨ Ý<00000000002a08c8>¨ __writeback_single_inode+0x54/0x27c Ý 1113.796322¨ Ý<00000000002a2c6c>¨ writeback_sb_inodes+0x284/0x4d8 Ý 1113.796325¨ Ý<00000000002a30b6>¨ wb_writeback+0x10e/0x374 Ý 1113.796327¨ Ý<00000000002a3d22>¨ wb_do_writeback+0x102/0x2e0 Ý 1113.796330¨ Ý<00000000002a3fa2>¨ bdi_writeback_thread+0xa2/0x270 Ý 1113.796333¨ Ý<00000000001581b2>¨ kthread+0xda/0xe4 Ý 1113.796338¨ Ý<0000000000629836>¨ kernel_thread_starter+0x6/0xc Ý 1113.796342¨ Ý<0000000000629830>¨ kernel_thread_starter+0x0/0xc Ý 1113.796345¨ Last Breaking-Event-Address: Ý 1113.796346¨ Ý<000000000030bc5e>¨ mpage_da_submit_io+0x38a/0x3c0 Ý 1113.796349¨ Ý 1113.796351¨ ---Ý end trace 45df5089b835470e ¨--- Ý 1113.796365¨ ------------Ý cut here ¨------------ Ý 1113.796367¨ WARNING: at kernel/exit.c:715 Ý 1113.796369¨ Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipt able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defra g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tab les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod dasd_eck d_mod dasd_mod lcs ctcm qeth fsm qdio ccwgroup dm_mirror dm_region_hash dm_log d m_mod Ý 1113.796393¨ CPU: 1 Tainted: G D 3.9.0-rc4+ #2 Ý 1113.796396¨ Process flush-253:1 (pid: 12418, task: 0000000003f04890, ksp: 000 0000032eab3b8) Ý 1113.796398¨ Krnl PSW : 0704e00180000000 0000000000133074 (do_exit+0x54/0xab8) Ý 1113.796404¨ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 EA: 3 Krnl GPRS: 0000000000000015 0000000032eabb60 0000000032eabb68 0000000000000000 Ý 1113.796408¨ 0000000000133058 ffffffffffffffff 0000000000000001 00 MORE... ZVM-RHTS ================================================================================ 0000032eab9c8 Ý 1113.796411¨ 0704e00180000000 000000000030bc62 0000000003f04890 000 0000000778d38 Ý 1113.796413¨ 000000000000000b 0000000000634140 0000000000133058 000 0000032eab4a0 Ý 1113.796423¨ Krnl Code: 0000000000133066: e32010080020 cg %r2,8(%r 1) 000000000013306c: a78403fa brc 8,133860 #0000000000133070: a7f40001 brc 15,133072 >0000000000133074: e31003180004 lg %r1,792 000000000013307a: 5810101c l %r1,28(%r1) 000000000013307e: c01b01ffff00 nilf %r1,33554176 0000000000133084: a7740481 brc 7,133986 0000000000133088: e310a2bc0012 lt %r1,700(%r10) Ý 1113.796447¨ Call Trace: Ý 1113.796449¨ (Ý<0000000000133058>¨ do_exit+0x38/0xab8) Ý 1113.796451¨ Ý<0000000000100ea4>¨ die+0x158/0x180 Ý 1113.796455¨ Ý<00000000006291fa>¨ do_trap+0x1a2/0x1a4 Ý 1113.796459¨ Ý<00000000006293ac>¨ illegal_op+0xfc/0x144 Ý 1113.796462¨ Ý<0000000000629974>¨ pgm_check_handler+0x138/0x13c Ý 1113.796464¨ Ý<000000000030bc62>¨ mpage_da_submit_io+0x38e/0x3c0 Ý 1113.796467¨ (Ý<000000000030b9a8>¨ mpage_da_submit_io+0xd4/0x3c0) Ý 1113.796470¨ Ý<000000000031204c>¨ mpage_da_map_and_submit+0x150/0x41c Ý 1113.796472¨ Ý<0000000000312bac>¨ ext4_da_writepages+0x364/0x628 Ý 1113.829664¨ Ý<00000000002a08c8>¨ __writeback_single_inode+0x54/0x27c Ý 1113.829674¨ Ý<00000000002a2c6c>¨ writeback_sb_inodes+0x284/0x4d8 Ý 1113.829681¨ Ý<00000000002a30b6>¨ wb_writeback+0x10e/0x374 Ý 1113.829691¨ Ý<00000000002a3d22>¨ wb_do_writeback+0x102/0x2e0 Ý 1113.829706¨ Ý<00000000002a3fa2>¨ bdi_writeback_thread+0xa2/0x270 Ý 1113.829715¨ Ý<00000000001581b2>¨ kthread+0xda/0xe4 Ý 1113.829725¨ Ý<0000000000629836>¨ kernel_thread_starter+0x6/0xc Ý 1113.829736¨ Ý<0000000000629830>¨ kernel_thread_starter+0x0/0xc Ý 1113.829753¨ Last Breaking-Event-Address: Ý 1113.829759¨ Ý<0000000000133070>¨ do_exit+0x50/0xab8 Ý 1113.829771¨ ---Ý end trace 45df5089b835470f ¨--- ^ permalink raw reply [flat|nested] 42+ messages in thread
* s390x: kernel BUG at fs/ext4/inode.c:1591! @ 2013-03-28 6:40 ` CAI Qian 0 siblings, 0 replies; 42+ messages in thread From: CAI Qian @ 2013-03-28 6:40 UTC (permalink / raw) To: LKML; +Cc: linux-s390, Steve Best, Theodore Ts'o, linux-ext4 System hung when running xfstests-dev 013 test case on an s390x guest. Never saw this on 3.9-rc3 before but need to double-check. Any idea? CAI Qian Ý 1113.795759¨ ------------Ý cut here ¨------------ Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! Ý 1113.795845¨ illegal operation: 0001 Ý#1¨ SMP Ý 1113.795848¨ Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipt able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defra g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tab les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod dasd_eck d_mod dasd_mod lcs ctcm qeth fsm qdio ccwgroup dm_mirror dm_region_hash dm_log d m_mod Ý 1113.795880¨ CPU: 1 Not tainted 3.9.0-rc4+ #2 Ý 1113.795882¨ Process flush-253:1 (pid: 12418, task: 0000000003f04890, ksp: 000 0000032eab3b8) Ý 1113.795885¨ Krnl PSW : 0704e00180000000 000000000030bc62 (mpage_da_submit_io+ 0x38e/0x3c0) Ý 1113.795895¨ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 EA: 3 Krnl GPRS: 0000000001000000 000000001b5823a8 0000000000000010 000000001b5823a8 Ý 1113.795900¨ 0000000000000000 00000000000000af 0000000000001000 000 0000032eab9c8 Ý 1113.795902¨ 000003d10053bb40 0000000032eaba30 00000000000000a1 000 0000032eaba98 Ý 1113.795905¨ 00000000000100b0 00000000000000a1 000000000030b9a8 000 0000032eab8a0 Ý 1113.795921¨ Krnl Code: 000000000030bc54: f0dca7f4fecf srp 2036(14, %r10),3791(%r15),12 MORE... ZVM-RHTS ================================================================================ 000000000030bc5a: a7f40001 brc 15,30bc5c #000000000030bc5e: a7f40001 brc 15,30bc60 >000000000030bc62: a7f40001 brc 15,30bc64 000000000030bc66: a7f40001 brc 15,30bc68 000000000030bc6a: 4120f0e8 la %r2,232(%r15) 000000000030bc6e: a7180000 lhi %r1,0 Ý 1113.796303¨ Call Trace: Ý 1113.796306¨ (Ý<000000000030b9a8>¨ mpage_da_submit_io+0xd4/0x3c0) Ý 1113.796311¨ Ý<000000000031204c>¨ mpage_da_map_and_submit+0x150/0x41c Ý 1113.796314¨ Ý<0000000000312bac>¨ ext4_da_writepages+0x364/0x628 Ý 1113.796317¨ Ý<00000000002a08c8>¨ __writeback_single_inode+0x54/0x27c Ý 1113.796322¨ Ý<00000000002a2c6c>¨ writeback_sb_inodes+0x284/0x4d8 Ý 1113.796325¨ Ý<00000000002a30b6>¨ wb_writeback+0x10e/0x374 Ý 1113.796327¨ Ý<00000000002a3d22>¨ wb_do_writeback+0x102/0x2e0 Ý 1113.796330¨ Ý<00000000002a3fa2>¨ bdi_writeback_thread+0xa2/0x270 Ý 1113.796333¨ Ý<00000000001581b2>¨ kthread+0xda/0xe4 Ý 1113.796338¨ Ý<0000000000629836>¨ kernel_thread_starter+0x6/0xc Ý 1113.796342¨ Ý<0000000000629830>¨ kernel_thread_starter+0x0/0xc Ý 1113.796345¨ Last Breaking-Event-Address: Ý 1113.796346¨ Ý<000000000030bc5e>¨ mpage_da_submit_io+0x38a/0x3c0 Ý 1113.796349¨ Ý 1113.796351¨ ---Ý end trace 45df5089b835470e ¨--- Ý 1113.796365¨ ------------Ý cut here ¨------------ Ý 1113.796367¨ WARNING: at kernel/exit.c:715 Ý 1113.796369¨ Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipt able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defra g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tab les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod dasd_eck d_mod dasd_mod lcs ctcm qeth fsm qdio ccwgroup dm_mirror dm_region_hash dm_log d m_mod Ý 1113.796393¨ CPU: 1 Tainted: G D 3.9.0-rc4+ #2 Ý 1113.796396¨ Process flush-253:1 (pid: 12418, task: 0000000003f04890, ksp: 000 0000032eab3b8) Ý 1113.796398¨ Krnl PSW : 0704e00180000000 0000000000133074 (do_exit+0x54/0xab8) Ý 1113.796404¨ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 EA: 3 Krnl GPRS: 0000000000000015 0000000032eabb60 0000000032eabb68 0000000000000000 Ý 1113.796408¨ 0000000000133058 ffffffffffffffff 0000000000000001 00 MORE... ZVM-RHTS ================================================================================ 0000032eab9c8 Ý 1113.796411¨ 0704e00180000000 000000000030bc62 0000000003f04890 000 0000000778d38 Ý 1113.796413¨ 000000000000000b 0000000000634140 0000000000133058 000 0000032eab4a0 Ý 1113.796423¨ Krnl Code: 0000000000133066: e32010080020 cg %r2,8(%r 1) 000000000013306c: a78403fa brc 8,133860 #0000000000133070: a7f40001 brc 15,133072 >0000000000133074: e31003180004 lg %r1,792 000000000013307a: 5810101c l %r1,28(%r1) 000000000013307e: c01b01ffff00 nilf %r1,33554176 0000000000133084: a7740481 brc 7,133986 0000000000133088: e310a2bc0012 lt %r1,700(%r10) Ý 1113.796447¨ Call Trace: Ý 1113.796449¨ (Ý<0000000000133058>¨ do_exit+0x38/0xab8) Ý 1113.796451¨ Ý<0000000000100ea4>¨ die+0x158/0x180 Ý 1113.796455¨ Ý<00000000006291fa>¨ do_trap+0x1a2/0x1a4 Ý 1113.796459¨ Ý<00000000006293ac>¨ illegal_op+0xfc/0x144 Ý 1113.796462¨ Ý<0000000000629974>¨ pgm_check_handler+0x138/0x13c Ý 1113.796464¨ Ý<000000000030bc62>¨ mpage_da_submit_io+0x38e/0x3c0 Ý 1113.796467¨ (Ý<000000000030b9a8>¨ mpage_da_submit_io+0xd4/0x3c0) Ý 1113.796470¨ Ý<000000000031204c>¨ mpage_da_map_and_submit+0x150/0x41c Ý 1113.796472¨ Ý<0000000000312bac>¨ ext4_da_writepages+0x364/0x628 Ý 1113.829664¨ Ý<00000000002a08c8>¨ __writeback_single_inode+0x54/0x27c Ý 1113.829674¨ Ý<00000000002a2c6c>¨ writeback_sb_inodes+0x284/0x4d8 Ý 1113.829681¨ Ý<00000000002a30b6>¨ wb_writeback+0x10e/0x374 Ý 1113.829691¨ Ý<00000000002a3d22>¨ wb_do_writeback+0x102/0x2e0 Ý 1113.829706¨ Ý<00000000002a3fa2>¨ bdi_writeback_thread+0xa2/0x270 Ý 1113.829715¨ Ý<00000000001581b2>¨ kthread+0xda/0xe4 Ý 1113.829725¨ Ý<0000000000629836>¨ kernel_thread_starter+0x6/0xc Ý 1113.829736¨ Ý<0000000000629830>¨ kernel_thread_starter+0x0/0xc Ý 1113.829753¨ Last Breaking-Event-Address: Ý 1113.829759¨ Ý<0000000000133070>¨ do_exit+0x50/0xab8 Ý 1113.829771¨ ---Ý end trace 45df5089b835470f ¨--- -- 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] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! 2013-03-28 6:40 ` CAI Qian @ 2013-03-28 9:44 ` CAI Qian -1 siblings, 0 replies; 42+ messages in thread From: CAI Qian @ 2013-03-28 9:44 UTC (permalink / raw) To: LKML; +Cc: linux-s390, Steve Best, Theodore Ts'o, linux-ext4 ----- Original Message ----- > From: "CAI Qian" <caiqian@redhat.com> > To: "LKML" <linux-kernel@vger.kernel.org> > Cc: "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" <sbest@redhat.com>, "Theodore Ts'o" <tytso@mit.edu>, > linux-ext4@vger.kernel.org > Sent: Thursday, March 28, 2013 2:40:33 PM > Subject: s390x: kernel BUG at fs/ext4/inode.c:1591! > > System hung when running xfstests-dev 013 test case on an s390x > guest. Never saw > this on 3.9-rc3 before but need to double-check. Any idea? Reproduced; bisect data so far, # git bisect log git bisect start # good: [a937536b868b8369b98967929045f1df54234323] Linux 3.9-rc3 git bisect good a937536b868b8369b98967929045f1df54234323 # bad: [9064171268d838b8f283fe111ef086b9479d059a] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes git bisect bad 9064171268d838b8f283fe111ef086b9479d059a # bad: [38d78e587d4960d0db94add518d27ee74bad2301] mqueue: sys_mq_open: do not call mnt_drop_write() if read-only git bisect bad 38d78e587d4960d0db94add518d27ee74bad2301 > > CAI Qian > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > Ý 1113.795845¨ illegal operation: 0001 Ý#1¨ SMP > Ý 1113.795848¨ Modules linked in: nf_conntrack_netbios_ns > nf_conntrack_broadcast > ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 > nf_defrag_ipv6 ipt > able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT > nf_conntrack_ipv4 nf_defra > g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables > ip6table_filter ip6_tab > les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c > dasd_fba_mod dasd_eck > d_mod dasd_mod lcs ctcm qeth fsm qdio ccwgroup dm_mirror > dm_region_hash dm_log d > m_mod > Ý 1113.795880¨ CPU: 1 Not tainted 3.9.0-rc4+ #2 > Ý 1113.795882¨ Process flush-253:1 (pid: 12418, task: > 0000000003f04890, ksp: 000 > 0000032eab3b8) > Ý 1113.795885¨ Krnl PSW : 0704e00180000000 000000000030bc62 > (mpage_da_submit_io+ > 0x38e/0x3c0) > Ý 1113.795895¨ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 > CC:2 PM:0 EA: > 3 > Krnl GPRS: 0000000001000000 000000001b5823a8 0000000000000010 > 000000001b5823a8 > Ý 1113.795900¨ 0000000000000000 00000000000000af > 0000000000001000 000 > 0000032eab9c8 > Ý 1113.795902¨ 000003d10053bb40 0000000032eaba30 > 00000000000000a1 000 > 0000032eaba98 > Ý 1113.795905¨ 00000000000100b0 00000000000000a1 > 000000000030b9a8 000 > 0000032eab8a0 > Ý 1113.795921¨ Krnl Code: 000000000030bc54: f0dca7f4fecf srp > 2036(14, > %r10),3791(%r15),12 > > MORE... > ZVM-RHTS > ================================================================================ > 000000000030bc5a: a7f40001 brc 15,30bc5c > #000000000030bc5e: a7f40001 brc 15,30bc60 > >000000000030bc62: a7f40001 brc 15,30bc64 > 000000000030bc66: a7f40001 brc 15,30bc68 > 000000000030bc6a: 4120f0e8 la %r2,232(%r15) > 000000000030bc6e: a7180000 lhi %r1,0 > Ý 1113.796303¨ Call Trace: > Ý 1113.796306¨ (Ý<000000000030b9a8>¨ mpage_da_submit_io+0xd4/0x3c0) > Ý 1113.796311¨ Ý<000000000031204c>¨ > mpage_da_map_and_submit+0x150/0x41c > Ý 1113.796314¨ Ý<0000000000312bac>¨ ext4_da_writepages+0x364/0x628 > Ý 1113.796317¨ Ý<00000000002a08c8>¨ > __writeback_single_inode+0x54/0x27c > Ý 1113.796322¨ Ý<00000000002a2c6c>¨ writeback_sb_inodes+0x284/0x4d8 > Ý 1113.796325¨ Ý<00000000002a30b6>¨ wb_writeback+0x10e/0x374 > Ý 1113.796327¨ Ý<00000000002a3d22>¨ wb_do_writeback+0x102/0x2e0 > Ý 1113.796330¨ Ý<00000000002a3fa2>¨ bdi_writeback_thread+0xa2/0x270 > Ý 1113.796333¨ Ý<00000000001581b2>¨ kthread+0xda/0xe4 > Ý 1113.796338¨ Ý<0000000000629836>¨ kernel_thread_starter+0x6/0xc > Ý 1113.796342¨ Ý<0000000000629830>¨ kernel_thread_starter+0x0/0xc > Ý 1113.796345¨ Last Breaking-Event-Address: > Ý 1113.796346¨ Ý<000000000030bc5e>¨ mpage_da_submit_io+0x38a/0x3c0 > Ý 1113.796349¨ > Ý 1113.796351¨ ---Ý end trace 45df5089b835470e ¨--- > Ý 1113.796365¨ ------------Ý cut here ¨------------ > Ý 1113.796367¨ WARNING: at kernel/exit.c:715 > Ý 1113.796369¨ Modules linked in: nf_conntrack_netbios_ns > nf_conntrack_broadcast > ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 > nf_defrag_ipv6 ipt > able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT > nf_conntrack_ipv4 nf_defra > g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables > ip6table_filter ip6_tab > les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c > dasd_fba_mod dasd_eck > d_mod dasd_mod lcs ctcm qeth fsm qdio ccwgroup dm_mirror > dm_region_hash dm_log d > m_mod > Ý 1113.796393¨ CPU: 1 Tainted: G D 3.9.0-rc4+ #2 > Ý 1113.796396¨ Process flush-253:1 (pid: 12418, task: > 0000000003f04890, ksp: 000 > 0000032eab3b8) > Ý 1113.796398¨ Krnl PSW : 0704e00180000000 0000000000133074 > (do_exit+0x54/0xab8) > > Ý 1113.796404¨ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 > CC:2 PM:0 EA: > 3 > Krnl GPRS: 0000000000000015 0000000032eabb60 0000000032eabb68 > 0000000000000000 > Ý 1113.796408¨ 0000000000133058 ffffffffffffffff > 0000000000000001 00 > > MORE... > ZVM-RHTS > ================================================================================ > 0000032eab9c8 > Ý 1113.796411¨ 0704e00180000000 000000000030bc62 > 0000000003f04890 000 > 0000000778d38 > Ý 1113.796413¨ 000000000000000b 0000000000634140 > 0000000000133058 000 > 0000032eab4a0 > Ý 1113.796423¨ Krnl Code: 0000000000133066: e32010080020 cg > %r2,8(%r > 1) > 000000000013306c: a78403fa brc 8,133860 > #0000000000133070: a7f40001 brc 15,133072 > >0000000000133074: e31003180004 lg %r1,792 > 000000000013307a: 5810101c l %r1,28(%r1) > 000000000013307e: c01b01ffff00 nilf %r1,33554176 > 0000000000133084: a7740481 brc 7,133986 > 0000000000133088: e310a2bc0012 lt %r1,700(%r10) > Ý 1113.796447¨ Call Trace: > Ý 1113.796449¨ (Ý<0000000000133058>¨ do_exit+0x38/0xab8) > Ý 1113.796451¨ Ý<0000000000100ea4>¨ die+0x158/0x180 > Ý 1113.796455¨ Ý<00000000006291fa>¨ do_trap+0x1a2/0x1a4 > Ý 1113.796459¨ Ý<00000000006293ac>¨ illegal_op+0xfc/0x144 > Ý 1113.796462¨ Ý<0000000000629974>¨ pgm_check_handler+0x138/0x13c > Ý 1113.796464¨ Ý<000000000030bc62>¨ mpage_da_submit_io+0x38e/0x3c0 > Ý 1113.796467¨ (Ý<000000000030b9a8>¨ mpage_da_submit_io+0xd4/0x3c0) > Ý 1113.796470¨ Ý<000000000031204c>¨ > mpage_da_map_and_submit+0x150/0x41c > Ý 1113.796472¨ Ý<0000000000312bac>¨ ext4_da_writepages+0x364/0x628 > Ý 1113.829664¨ Ý<00000000002a08c8>¨ > __writeback_single_inode+0x54/0x27c > Ý 1113.829674¨ Ý<00000000002a2c6c>¨ writeback_sb_inodes+0x284/0x4d8 > Ý 1113.829681¨ Ý<00000000002a30b6>¨ wb_writeback+0x10e/0x374 > Ý 1113.829691¨ Ý<00000000002a3d22>¨ wb_do_writeback+0x102/0x2e0 > Ý 1113.829706¨ Ý<00000000002a3fa2>¨ bdi_writeback_thread+0xa2/0x270 > Ý 1113.829715¨ Ý<00000000001581b2>¨ kthread+0xda/0xe4 > Ý 1113.829725¨ Ý<0000000000629836>¨ kernel_thread_starter+0x6/0xc > Ý 1113.829736¨ Ý<0000000000629830>¨ kernel_thread_starter+0x0/0xc > Ý 1113.829753¨ Last Breaking-Event-Address: > Ý 1113.829759¨ Ý<0000000000133070>¨ do_exit+0x50/0xab8 > Ý 1113.829771¨ ---Ý end trace 45df5089b835470f ¨--- ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! @ 2013-03-28 9:44 ` CAI Qian 0 siblings, 0 replies; 42+ messages in thread From: CAI Qian @ 2013-03-28 9:44 UTC (permalink / raw) To: LKML; +Cc: linux-s390, Steve Best, Theodore Ts'o, linux-ext4 ----- Original Message ----- > From: "CAI Qian" <caiqian@redhat.com> > To: "LKML" <linux-kernel@vger.kernel.org> > Cc: "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" <sbest@redhat.com>, "Theodore Ts'o" <tytso@mit.edu>, > linux-ext4@vger.kernel.org > Sent: Thursday, March 28, 2013 2:40:33 PM > Subject: s390x: kernel BUG at fs/ext4/inode.c:1591! > > System hung when running xfstests-dev 013 test case on an s390x > guest. Never saw > this on 3.9-rc3 before but need to double-check. Any idea? Reproduced; bisect data so far, # git bisect log git bisect start # good: [a937536b868b8369b98967929045f1df54234323] Linux 3.9-rc3 git bisect good a937536b868b8369b98967929045f1df54234323 # bad: [9064171268d838b8f283fe111ef086b9479d059a] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes git bisect bad 9064171268d838b8f283fe111ef086b9479d059a # bad: [38d78e587d4960d0db94add518d27ee74bad2301] mqueue: sys_mq_open: do not call mnt_drop_write() if read-only git bisect bad 38d78e587d4960d0db94add518d27ee74bad2301 > > CAI Qian > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > Ý 1113.795845¨ illegal operation: 0001 Ý#1¨ SMP > Ý 1113.795848¨ Modules linked in: nf_conntrack_netbios_ns > nf_conntrack_broadcast > ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 > nf_defrag_ipv6 ipt > able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT > nf_conntrack_ipv4 nf_defra > g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables > ip6table_filter ip6_tab > les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c > dasd_fba_mod dasd_eck > d_mod dasd_mod lcs ctcm qeth fsm qdio ccwgroup dm_mirror > dm_region_hash dm_log d > m_mod > Ý 1113.795880¨ CPU: 1 Not tainted 3.9.0-rc4+ #2 > Ý 1113.795882¨ Process flush-253:1 (pid: 12418, task: > 0000000003f04890, ksp: 000 > 0000032eab3b8) > Ý 1113.795885¨ Krnl PSW : 0704e00180000000 000000000030bc62 > (mpage_da_submit_io+ > 0x38e/0x3c0) > Ý 1113.795895¨ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 > CC:2 PM:0 EA: > 3 > Krnl GPRS: 0000000001000000 000000001b5823a8 0000000000000010 > 000000001b5823a8 > Ý 1113.795900¨ 0000000000000000 00000000000000af > 0000000000001000 000 > 0000032eab9c8 > Ý 1113.795902¨ 000003d10053bb40 0000000032eaba30 > 00000000000000a1 000 > 0000032eaba98 > Ý 1113.795905¨ 00000000000100b0 00000000000000a1 > 000000000030b9a8 000 > 0000032eab8a0 > Ý 1113.795921¨ Krnl Code: 000000000030bc54: f0dca7f4fecf srp > 2036(14, > %r10),3791(%r15),12 > > MORE... > ZVM-RHTS > ================================================================================ > 000000000030bc5a: a7f40001 brc 15,30bc5c > #000000000030bc5e: a7f40001 brc 15,30bc60 > >000000000030bc62: a7f40001 brc 15,30bc64 > 000000000030bc66: a7f40001 brc 15,30bc68 > 000000000030bc6a: 4120f0e8 la %r2,232(%r15) > 000000000030bc6e: a7180000 lhi %r1,0 > Ý 1113.796303¨ Call Trace: > Ý 1113.796306¨ (Ý<000000000030b9a8>¨ mpage_da_submit_io+0xd4/0x3c0) > Ý 1113.796311¨ Ý<000000000031204c>¨ > mpage_da_map_and_submit+0x150/0x41c > Ý 1113.796314¨ Ý<0000000000312bac>¨ ext4_da_writepages+0x364/0x628 > Ý 1113.796317¨ Ý<00000000002a08c8>¨ > __writeback_single_inode+0x54/0x27c > Ý 1113.796322¨ Ý<00000000002a2c6c>¨ writeback_sb_inodes+0x284/0x4d8 > Ý 1113.796325¨ Ý<00000000002a30b6>¨ wb_writeback+0x10e/0x374 > Ý 1113.796327¨ Ý<00000000002a3d22>¨ wb_do_writeback+0x102/0x2e0 > Ý 1113.796330¨ Ý<00000000002a3fa2>¨ bdi_writeback_thread+0xa2/0x270 > Ý 1113.796333¨ Ý<00000000001581b2>¨ kthread+0xda/0xe4 > Ý 1113.796338¨ Ý<0000000000629836>¨ kernel_thread_starter+0x6/0xc > Ý 1113.796342¨ Ý<0000000000629830>¨ kernel_thread_starter+0x0/0xc > Ý 1113.796345¨ Last Breaking-Event-Address: > Ý 1113.796346¨ Ý<000000000030bc5e>¨ mpage_da_submit_io+0x38a/0x3c0 > Ý 1113.796349¨ > Ý 1113.796351¨ ---Ý end trace 45df5089b835470e ¨--- > Ý 1113.796365¨ ------------Ý cut here ¨------------ > Ý 1113.796367¨ WARNING: at kernel/exit.c:715 > Ý 1113.796369¨ Modules linked in: nf_conntrack_netbios_ns > nf_conntrack_broadcast > ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 > nf_defrag_ipv6 ipt > able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT > nf_conntrack_ipv4 nf_defra > g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables > ip6table_filter ip6_tab > les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c > dasd_fba_mod dasd_eck > d_mod dasd_mod lcs ctcm qeth fsm qdio ccwgroup dm_mirror > dm_region_hash dm_log d > m_mod > Ý 1113.796393¨ CPU: 1 Tainted: G D 3.9.0-rc4+ #2 > Ý 1113.796396¨ Process flush-253:1 (pid: 12418, task: > 0000000003f04890, ksp: 000 > 0000032eab3b8) > Ý 1113.796398¨ Krnl PSW : 0704e00180000000 0000000000133074 > (do_exit+0x54/0xab8) > > Ý 1113.796404¨ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 > CC:2 PM:0 EA: > 3 > Krnl GPRS: 0000000000000015 0000000032eabb60 0000000032eabb68 > 0000000000000000 > Ý 1113.796408¨ 0000000000133058 ffffffffffffffff > 0000000000000001 00 > > MORE... > ZVM-RHTS > ================================================================================ > 0000032eab9c8 > Ý 1113.796411¨ 0704e00180000000 000000000030bc62 > 0000000003f04890 000 > 0000000778d38 > Ý 1113.796413¨ 000000000000000b 0000000000634140 > 0000000000133058 000 > 0000032eab4a0 > Ý 1113.796423¨ Krnl Code: 0000000000133066: e32010080020 cg > %r2,8(%r > 1) > 000000000013306c: a78403fa brc 8,133860 > #0000000000133070: a7f40001 brc 15,133072 > >0000000000133074: e31003180004 lg %r1,792 > 000000000013307a: 5810101c l %r1,28(%r1) > 000000000013307e: c01b01ffff00 nilf %r1,33554176 > 0000000000133084: a7740481 brc 7,133986 > 0000000000133088: e310a2bc0012 lt %r1,700(%r10) > Ý 1113.796447¨ Call Trace: > Ý 1113.796449¨ (Ý<0000000000133058>¨ do_exit+0x38/0xab8) > Ý 1113.796451¨ Ý<0000000000100ea4>¨ die+0x158/0x180 > Ý 1113.796455¨ Ý<00000000006291fa>¨ do_trap+0x1a2/0x1a4 > Ý 1113.796459¨ Ý<00000000006293ac>¨ illegal_op+0xfc/0x144 > Ý 1113.796462¨ Ý<0000000000629974>¨ pgm_check_handler+0x138/0x13c > Ý 1113.796464¨ Ý<000000000030bc62>¨ mpage_da_submit_io+0x38e/0x3c0 > Ý 1113.796467¨ (Ý<000000000030b9a8>¨ mpage_da_submit_io+0xd4/0x3c0) > Ý 1113.796470¨ Ý<000000000031204c>¨ > mpage_da_map_and_submit+0x150/0x41c > Ý 1113.796472¨ Ý<0000000000312bac>¨ ext4_da_writepages+0x364/0x628 > Ý 1113.829664¨ Ý<00000000002a08c8>¨ > __writeback_single_inode+0x54/0x27c > Ý 1113.829674¨ Ý<00000000002a2c6c>¨ writeback_sb_inodes+0x284/0x4d8 > Ý 1113.829681¨ Ý<00000000002a30b6>¨ wb_writeback+0x10e/0x374 > Ý 1113.829691¨ Ý<00000000002a3d22>¨ wb_do_writeback+0x102/0x2e0 > Ý 1113.829706¨ Ý<00000000002a3fa2>¨ bdi_writeback_thread+0xa2/0x270 > Ý 1113.829715¨ Ý<00000000001581b2>¨ kthread+0xda/0xe4 > Ý 1113.829725¨ Ý<0000000000629836>¨ kernel_thread_starter+0x6/0xc > Ý 1113.829736¨ Ý<0000000000629830>¨ kernel_thread_starter+0x0/0xc > Ý 1113.829753¨ Last Breaking-Event-Address: > Ý 1113.829759¨ Ý<0000000000133070>¨ do_exit+0x50/0xab8 > Ý 1113.829771¨ ---Ý end trace 45df5089b835470f ¨--- -- 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] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! 2013-03-28 6:40 ` CAI Qian (?) (?) @ 2013-03-28 12:05 ` Theodore Ts'o 2013-03-28 14:56 ` Dmitry Monakhov 2013-03-29 9:27 ` CAI Qian -1 siblings, 2 replies; 42+ messages in thread From: Theodore Ts'o @ 2013-03-28 12:05 UTC (permalink / raw) To: CAI Qian; +Cc: LKML, linux-s390, Steve Best, linux-ext4 On Thu, Mar 28, 2013 at 02:40:33AM -0400, CAI Qian wrote: > System hung when running xfstests-dev 013 test case on an s390x guest. Never saw > this on 3.9-rc3 before but need to double-check. Any idea? > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! thanks for the report. What kernel version did this come from? Was it 3.9-rc4? (line 1591 for 3.9-rc3 doesn't contain a BUG_ON). If it is indeed 3.9-rc4, it would be helpful, since you can reproduce the problem, to insert a debugging printk which fires when bh->b_blocknr != pblock before the BUG_ON, and have it print the b_blocknr and pblock values. Thanks, - Ted ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! 2013-03-28 12:05 ` Theodore Ts'o @ 2013-03-28 14:56 ` Dmitry Monakhov 2013-03-29 8:53 ` CAI Qian 2013-03-29 9:27 ` CAI Qian 1 sibling, 1 reply; 42+ messages in thread From: Dmitry Monakhov @ 2013-03-28 14:56 UTC (permalink / raw) To: Theodore Ts'o, CAI Qian; +Cc: LKML, linux-s390, Steve Best, linux-ext4 On Thu, 28 Mar 2013 08:05:17 -0400, Theodore Ts'o <tytso@mit.edu> wrote: > On Thu, Mar 28, 2013 at 02:40:33AM -0400, CAI Qian wrote: > > System hung when running xfstests-dev 013 test case on an s390x guest. Never saw > > this on 3.9-rc3 before but need to double-check. Any idea? > > > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > > thanks for the report. What kernel version did this come from? Was > it 3.9-rc4? (line 1591 for 3.9-rc3 doesn't contain a BUG_ON). > > If it is indeed 3.9-rc4, it would be helpful, since you can reproduce > the problem, to insert a debugging printk which fires when > bh->b_blocknr != pblock before the BUG_ON, and have it print the > b_blocknr and pblock values. I've triggered this bug on before at the time i've worked on e4defrag functionality, but AFAIK all related issues was aready fixed and 013 has nothing with e4defrag. But still bh->b_blocknr under us. So other obvious place I suspect is puch_hole but this also not true because 013 use fsstress test in vegetarian mode: "-f rmdir=10 -f link=10 -f creat=10 -f mkdir=10 -f rename=30 -f stat=30 -f unlink=30 -f truncate=20" So the only place I suspect is some unknown bug in extent status tree Can you please enable ES_AGGRESSIVE_TEST and rerun xfstest. > > Thanks, > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! 2013-03-28 14:56 ` Dmitry Monakhov @ 2013-03-29 8:53 ` CAI Qian 2013-03-29 10:08 ` Dmitry Monakhov 0 siblings, 1 reply; 42+ messages in thread From: CAI Qian @ 2013-03-29 8:53 UTC (permalink / raw) To: Dmitry Monakhov Cc: LKML, linux-s390, Steve Best, linux-ext4, Theodore Ts'o ----- Original Message ----- > From: "Dmitry Monakhov" <dmonakhov@openvz.org> > To: "Theodore Ts'o" <tytso@mit.edu>, "CAI Qian" <caiqian@redhat.com> > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" > <sbest@redhat.com>, linux-ext4@vger.kernel.org > Sent: Thursday, March 28, 2013 10:56:37 PM > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > On Thu, 28 Mar 2013 08:05:17 -0400, Theodore Ts'o <tytso@mit.edu> > wrote: > > On Thu, Mar 28, 2013 at 02:40:33AM -0400, CAI Qian wrote: > > > System hung when running xfstests-dev 013 test case on an s390x > > > guest. Never saw > > > this on 3.9-rc3 before but need to double-check. Any idea? > > > > > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > > > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > > > > thanks for the report. What kernel version did this come from? > > Was > > it 3.9-rc4? (line 1591 for 3.9-rc3 doesn't contain a BUG_ON). > > > > If it is indeed 3.9-rc4, it would be helpful, since you can > > reproduce > > the problem, to insert a debugging printk which fires when > > bh->b_blocknr != pblock before the BUG_ON, and have it print the > > b_blocknr and pblock values. > I've triggered this bug on before at the time i've worked on > e4defrag functionality, but AFAIK all related issues was aready fixed > and 013 has nothing with e4defrag. > But still bh->b_blocknr under us. So other obvious place I suspect is > puch_hole but this also not true because 013 use fsstress > test in vegetarian mode: "-f rmdir=10 -f link=10 -f creat=10 -f > mkdir=10 > -f rename=30 -f stat=30 -f unlink=30 -f truncate=20" > So the only place I suspect is some unknown bug in extent status tree > Can you please enable ES_AGGRESSIVE_TEST and rerun xfstest. What is ES_AGGRESSIVE_TEST and how can it enable it? > > > > Thanks, > > > > - Ted > > -- > > To unsubscribe from this list: send the line "unsubscribe > > linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! 2013-03-29 8:53 ` CAI Qian @ 2013-03-29 10:08 ` Dmitry Monakhov 0 siblings, 0 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-03-29 10:08 UTC (permalink / raw) To: CAI Qian; +Cc: LKML, linux-s390, Steve Best, linux-ext4, Theodore Ts'o [-- Attachment #1: Type: text/plain, Size: 2106 bytes --] On Fri, 29 Mar 2013 04:53:43 -0400 (EDT), CAI Qian <caiqian@redhat.com> wrote: > > > ----- Original Message ----- > > From: "Dmitry Monakhov" <dmonakhov@openvz.org> > > To: "Theodore Ts'o" <tytso@mit.edu>, "CAI Qian" <caiqian@redhat.com> > > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" > > <sbest@redhat.com>, linux-ext4@vger.kernel.org > > Sent: Thursday, March 28, 2013 10:56:37 PM > > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > > > On Thu, 28 Mar 2013 08:05:17 -0400, Theodore Ts'o <tytso@mit.edu> > > wrote: > > > On Thu, Mar 28, 2013 at 02:40:33AM -0400, CAI Qian wrote: > > > > System hung when running xfstests-dev 013 test case on an s390x > > > > guest. Never saw > > > > this on 3.9-rc3 before but need to double-check. Any idea? > > > > > > > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > > > > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > > > > > > thanks for the report. What kernel version did this come from? > > > Was > > > it 3.9-rc4? (line 1591 for 3.9-rc3 doesn't contain a BUG_ON). > > > > > > If it is indeed 3.9-rc4, it would be helpful, since you can > > > reproduce > > > the problem, to insert a debugging printk which fires when > > > bh->b_blocknr != pblock before the BUG_ON, and have it print the > > > b_blocknr and pblock values. > > I've triggered this bug on before at the time i've worked on > > e4defrag functionality, but AFAIK all related issues was aready fixed > > and 013 has nothing with e4defrag. > > But still bh->b_blocknr under us. So other obvious place I suspect is > > puch_hole but this also not true because 013 use fsstress > > test in vegetarian mode: "-f rmdir=10 -f link=10 -f creat=10 -f > > mkdir=10 > > -f rename=30 -f stat=30 -f unlink=30 -f truncate=20" > > So the only place I suspect is some unknown bug in extent status tree > > Can you please enable ES_AGGRESSIVE_TEST and rerun xfstest. > What is ES_AGGRESSIVE_TEST and how can it enable it? Please apply patch. It should helps to spot an issue [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: ext4-map_corruption_debug.patch --] [-- Type: text/x-patch, Size: 1593 bytes --] diff --git a/fs/ext4/extents_status.h b/fs/ext4/extents_status.h index d8e2d4d..70233a6 100644 --- a/fs/ext4/extents_status.h +++ b/fs/ext4/extents_status.h @@ -24,7 +24,7 @@ * With ES_AGGRESSIVE_TEST defined, the result of es caching will be * checked with old map_block's result. */ -#define ES_AGGRESSIVE_TEST__ +#define ES_AGGRESSIVE_TEST /* * These flags live in the high bits of extent_status.es_pblk diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index b3a5213..676c3e1 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1588,7 +1588,8 @@ static int mpage_da_submit_io(struct mpage_da_data *mpd, } if (buffer_unwritten(bh) || buffer_mapped(bh)) - BUG_ON(bh->b_blocknr != pblock); + if (bh->b_blocknr != pblock) + goto map_corruption; if (map->m_flags & EXT4_MAP_UNINIT) set_buffer_uninit(bh); clear_buffer_unwritten(bh); @@ -1627,6 +1628,17 @@ static int mpage_da_submit_io(struct mpage_da_data *mpd, } ext4_io_submit(&io_submit); return ret; + +map_corruption: + printk(KERN_ERR "mpage_da_submit_io failed block=%llu != b_blocknr=%llu\n", + (unsigned long long)pblock, (unsigned long long)bh->b_blocknr); + printk(KERN_ERR "ino:%ld lbkl:%lu, b_state=0x%08lx, b_size=%zu\n", + inode->i_ino, cur_logical, bh->b_state, bh->b_size); + /* We have triggered emergency situation. Do not waste our time on + * useless cleanup in order to pretend what situation is under controll. + * Just panic. */ + BUG(); + return -EIO; } static void ext4_da_block_invalidatepages(struct mpage_da_data *mpd) [-- Attachment #3: Type: text/plain, Size: 333 bytes --] > > > > > > Thanks, > > > > > > - Ted > > > -- > > > To unsubscribe from this list: send the line "unsubscribe > > > linux-kernel" in > > > the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > ^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! 2013-03-28 12:05 ` Theodore Ts'o 2013-03-28 14:56 ` Dmitry Monakhov @ 2013-03-29 9:27 ` CAI Qian 2013-04-01 6:07 ` Dmitry Monakhov 1 sibling, 1 reply; 42+ messages in thread From: CAI Qian @ 2013-03-29 9:27 UTC (permalink / raw) To: Theodore Ts'o; +Cc: LKML, linux-s390, Steve Best, linux-ext4 ----- Original Message ----- > From: "Theodore Ts'o" <tytso@mit.edu> > To: "CAI Qian" <caiqian@redhat.com> > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" > <sbest@redhat.com>, linux-ext4@vger.kernel.org > Sent: Thursday, March 28, 2013 8:05:17 PM > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > On Thu, Mar 28, 2013 at 02:40:33AM -0400, CAI Qian wrote: > > System hung when running xfstests-dev 013 test case on an s390x > > guest. Never saw > > this on 3.9-rc3 before but need to double-check. Any idea? > > > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > > thanks for the report. What kernel version did this come from? Was > it 3.9-rc4? (line 1591 for 3.9-rc3 doesn't contain a BUG_ON). Yes, the lastest mainline. > > If it is indeed 3.9-rc4, it would be helpful, since you can reproduce > the problem, to insert a debugging printk which fires when > bh->b_blocknr != pblock before the BUG_ON, and have it print the > b_blocknr and pblock values. bh->b_blocknr=100346 pblock=66797 Bisecting results so far, git bisect start # good: [a937536b868b8369b98967929045f1df54234323] Linux 3.9-rc3 git bisect good a937536b868b8369b98967929045f1df54234323 # bad: [9064171268d838b8f283fe111ef086b9479d059a] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes git bisect bad 9064171268d838b8f283fe111ef086b9479d059a # bad: [38d78e587d4960d0db94add518d27ee74bad2301] mqueue: sys_mq_open: do not call mnt_drop_write() if read-only git bisect bad 38d78e587d4960d0db94add518d27ee74bad2301 # good: [e7489622d3603b7d161b484dcd340d9f678b0c7a] Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 git bisect good e7489622d3603b7d161b484dcd340d9f678b0c7a # good: [172a271b5e090da7468c66b9ccbcdb3d929eed75] Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux git bisect good 172a271b5e090da7468c66b9ccbcdb3d929eed75 # good: [0a7e453103b9718d357688b83bb968ee108cc874] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux git bisect good 0a7e453103b9718d357688b83bb968ee108cc874 # bad: [0e401101db49959f5783f6ee9e676124b5a183ac] ext4: fix memory leakage in mext_check_coverage git bisect bad 0e401101db49959f5783f6ee9e676124b5a183ac CAI Qian > > Thanks, > > - Ted > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! 2013-03-29 9:27 ` CAI Qian @ 2013-04-01 6:07 ` Dmitry Monakhov 0 siblings, 0 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-01 6:07 UTC (permalink / raw) To: CAI Qian, Theodore Ts'o; +Cc: LKML, linux-s390, Steve Best, linux-ext4 On Fri, 29 Mar 2013 05:27:02 -0400 (EDT), CAI Qian <caiqian@redhat.com> wrote: > I've spent a half of weekend by trying to create s390x guest image, without any success. Can you please share it. > > ----- Original Message ----- > > From: "Theodore Ts'o" <tytso@mit.edu> > > To: "CAI Qian" <caiqian@redhat.com> > > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" > > <sbest@redhat.com>, linux-ext4@vger.kernel.org > > Sent: Thursday, March 28, 2013 8:05:17 PM > > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > > > On Thu, Mar 28, 2013 at 02:40:33AM -0400, CAI Qian wrote: > > > System hung when running xfstests-dev 013 test case on an s390x > > > guest. Never saw > > > this on 3.9-rc3 before but need to double-check. Any idea? > > > > > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > > > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > > > > thanks for the report. What kernel version did this come from? Was > > it 3.9-rc4? (line 1591 for 3.9-rc3 doesn't contain a BUG_ON). > Yes, the lastest mainline. > > > > If it is indeed 3.9-rc4, it would be helpful, since you can reproduce > > the problem, to insert a debugging printk which fires when > > bh->b_blocknr != pblock before the BUG_ON, and have it print the > > b_blocknr and pblock values. > bh->b_blocknr=100346 > pblock=66797 > > Bisecting results so far, > git bisect start > # good: [a937536b868b8369b98967929045f1df54234323] Linux 3.9-rc3 > git bisect good a937536b868b8369b98967929045f1df54234323 > # bad: [9064171268d838b8f283fe111ef086b9479d059a] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes > git bisect bad 9064171268d838b8f283fe111ef086b9479d059a > # bad: [38d78e587d4960d0db94add518d27ee74bad2301] mqueue: sys_mq_open: do not call mnt_drop_write() if read-only > git bisect bad 38d78e587d4960d0db94add518d27ee74bad2301 > # good: [e7489622d3603b7d161b484dcd340d9f678b0c7a] Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 > git bisect good e7489622d3603b7d161b484dcd340d9f678b0c7a > # good: [172a271b5e090da7468c66b9ccbcdb3d929eed75] Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux > git bisect good 172a271b5e090da7468c66b9ccbcdb3d929eed75 > # good: [0a7e453103b9718d357688b83bb968ee108cc874] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux > git bisect good 0a7e453103b9718d357688b83bb968ee108cc874 > # bad: [0e401101db49959f5783f6ee9e676124b5a183ac] ext4: fix memory leakage in mext_check_coverage > git bisect bad 0e401101db49959f5783f6ee9e676124b5a183ac > CAI Qian > > > > Thanks, > > > > - Ted > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! @ 2013-04-01 6:07 ` Dmitry Monakhov 0 siblings, 0 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-01 6:07 UTC (permalink / raw) To: CAI Qian, Theodore Ts'o; +Cc: LKML, linux-s390, Steve Best, linux-ext4 On Fri, 29 Mar 2013 05:27:02 -0400 (EDT), CAI Qian <caiqian@redhat.com> wrote: > I've spent a half of weekend by trying to create s390x guest image, without any success. Can you please share it. > > ----- Original Message ----- > > From: "Theodore Ts'o" <tytso@mit.edu> > > To: "CAI Qian" <caiqian@redhat.com> > > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" > > <sbest@redhat.com>, linux-ext4@vger.kernel.org > > Sent: Thursday, March 28, 2013 8:05:17 PM > > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > > > On Thu, Mar 28, 2013 at 02:40:33AM -0400, CAI Qian wrote: > > > System hung when running xfstests-dev 013 test case on an s390x > > > guest. Never saw > > > this on 3.9-rc3 before but need to double-check. Any idea? > > > > > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > > > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > > > > thanks for the report. What kernel version did this come from? Was > > it 3.9-rc4? (line 1591 for 3.9-rc3 doesn't contain a BUG_ON). > Yes, the lastest mainline. > > > > If it is indeed 3.9-rc4, it would be helpful, since you can reproduce > > the problem, to insert a debugging printk which fires when > > bh->b_blocknr != pblock before the BUG_ON, and have it print the > > b_blocknr and pblock values. > bh->b_blocknr=100346 > pblock=66797 > > Bisecting results so far, > git bisect start > # good: [a937536b868b8369b98967929045f1df54234323] Linux 3.9-rc3 > git bisect good a937536b868b8369b98967929045f1df54234323 > # bad: [9064171268d838b8f283fe111ef086b9479d059a] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes > git bisect bad 9064171268d838b8f283fe111ef086b9479d059a > # bad: [38d78e587d4960d0db94add518d27ee74bad2301] mqueue: sys_mq_open: do not call mnt_drop_write() if read-only > git bisect bad 38d78e587d4960d0db94add518d27ee74bad2301 > # good: [e7489622d3603b7d161b484dcd340d9f678b0c7a] Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 > git bisect good e7489622d3603b7d161b484dcd340d9f678b0c7a > # good: [172a271b5e090da7468c66b9ccbcdb3d929eed75] Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux > git bisect good 172a271b5e090da7468c66b9ccbcdb3d929eed75 > # good: [0a7e453103b9718d357688b83bb968ee108cc874] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux > git bisect good 0a7e453103b9718d357688b83bb968ee108cc874 > # bad: [0e401101db49959f5783f6ee9e676124b5a183ac] ext4: fix memory leakage in mext_check_coverage > git bisect bad 0e401101db49959f5783f6ee9e676124b5a183ac > CAI Qian > > > > Thanks, > > > > - Ted > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! 2013-04-01 6:07 ` Dmitry Monakhov @ 2013-04-01 6:30 ` CAI Qian -1 siblings, 0 replies; 42+ messages in thread From: CAI Qian @ 2013-04-01 6:30 UTC (permalink / raw) To: Dmitry Monakhov Cc: Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 ----- Original Message ----- > From: "Dmitry Monakhov" <dmonakhov@openvz.org> > To: "CAI Qian" <caiqian@redhat.com>, "Theodore Ts'o" <tytso@mit.edu> > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" > <sbest@redhat.com>, linux-ext4@vger.kernel.org > Sent: Monday, April 1, 2013 2:07:35 PM > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > On Fri, 29 Mar 2013 05:27:02 -0400 (EDT), CAI Qian <caiqian@redhat.com> > wrote: > > > I've spent a half of weekend by trying to create s390x guest image, > without any success. Can you please share it. Well, do you have something like IBM system-Z? http://en.wikipedia.org/wiki/IBM_System_z10 Also can be reproduced on system-p, http://en.wikipedia.org/wiki/IBM_System_p Never seen it on x86 so far though. CAI Qian > > > > ----- Original Message ----- > > > From: "Theodore Ts'o" <tytso@mit.edu> > > > To: "CAI Qian" <caiqian@redhat.com> > > > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" > > > <linux-s390@vger.kernel.org>, "Steve Best" > > > <sbest@redhat.com>, linux-ext4@vger.kernel.org > > > Sent: Thursday, March 28, 2013 8:05:17 PM > > > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > > > > > On Thu, Mar 28, 2013 at 02:40:33AM -0400, CAI Qian wrote: > > > > System hung when running xfstests-dev 013 test case on an s390x > > > > guest. Never saw > > > > this on 3.9-rc3 before but need to double-check. Any idea? > > > > > > > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > > > > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > > > > > > thanks for the report. What kernel version did this come from? Was > > > it 3.9-rc4? (line 1591 for 3.9-rc3 doesn't contain a BUG_ON). > > Yes, the lastest mainline. > > > > > > If it is indeed 3.9-rc4, it would be helpful, since you can reproduce > > > the problem, to insert a debugging printk which fires when > > > bh->b_blocknr != pblock before the BUG_ON, and have it print the > > > b_blocknr and pblock values. > > bh->b_blocknr=100346 > > pblock=66797 > > > > Bisecting results so far, > > git bisect start > > # good: [a937536b868b8369b98967929045f1df54234323] Linux 3.9-rc3 > > git bisect good a937536b868b8369b98967929045f1df54234323 > > # bad: [9064171268d838b8f283fe111ef086b9479d059a] Merge tag 'for-linus' of > > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes > > git bisect bad 9064171268d838b8f283fe111ef086b9479d059a > > # bad: [38d78e587d4960d0db94add518d27ee74bad2301] mqueue: sys_mq_open: do > > not call mnt_drop_write() if read-only > > git bisect bad 38d78e587d4960d0db94add518d27ee74bad2301 > > # good: [e7489622d3603b7d161b484dcd340d9f678b0c7a] Merge tag 'arm64-fixes' > > of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 > > git bisect good e7489622d3603b7d161b484dcd340d9f678b0c7a > > # good: [172a271b5e090da7468c66b9ccbcdb3d929eed75] Merge branch 'drm-fixes' > > of git://people.freedesktop.org/~airlied/linux > > git bisect good 172a271b5e090da7468c66b9ccbcdb3d929eed75 > > # good: [0a7e453103b9718d357688b83bb968ee108cc874] Merge branch 'next' of > > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux > > git bisect good 0a7e453103b9718d357688b83bb968ee108cc874 > > # bad: [0e401101db49959f5783f6ee9e676124b5a183ac] ext4: fix memory leakage > > in mext_check_coverage > > git bisect bad 0e401101db49959f5783f6ee9e676124b5a183ac > > CAI Qian > > > > > > Thanks, > > > > > > - Ted > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! @ 2013-04-01 6:30 ` CAI Qian 0 siblings, 0 replies; 42+ messages in thread From: CAI Qian @ 2013-04-01 6:30 UTC (permalink / raw) To: Dmitry Monakhov Cc: Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 ----- Original Message ----- > From: "Dmitry Monakhov" <dmonakhov@openvz.org> > To: "CAI Qian" <caiqian@redhat.com>, "Theodore Ts'o" <tytso@mit.edu> > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" > <sbest@redhat.com>, linux-ext4@vger.kernel.org > Sent: Monday, April 1, 2013 2:07:35 PM > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > On Fri, 29 Mar 2013 05:27:02 -0400 (EDT), CAI Qian <caiqian@redhat.com> > wrote: > > > I've spent a half of weekend by trying to create s390x guest image, > without any success. Can you please share it. Well, do you have something like IBM system-Z? http://en.wikipedia.org/wiki/IBM_System_z10 Also can be reproduced on system-p, http://en.wikipedia.org/wiki/IBM_System_p Never seen it on x86 so far though. CAI Qian > > > > ----- Original Message ----- > > > From: "Theodore Ts'o" <tytso@mit.edu> > > > To: "CAI Qian" <caiqian@redhat.com> > > > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" > > > <linux-s390@vger.kernel.org>, "Steve Best" > > > <sbest@redhat.com>, linux-ext4@vger.kernel.org > > > Sent: Thursday, March 28, 2013 8:05:17 PM > > > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > > > > > On Thu, Mar 28, 2013 at 02:40:33AM -0400, CAI Qian wrote: > > > > System hung when running xfstests-dev 013 test case on an s390x > > > > guest. Never saw > > > > this on 3.9-rc3 before but need to double-check. Any idea? > > > > > > > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > > > > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > > > > > > thanks for the report. What kernel version did this come from? Was > > > it 3.9-rc4? (line 1591 for 3.9-rc3 doesn't contain a BUG_ON). > > Yes, the lastest mainline. > > > > > > If it is indeed 3.9-rc4, it would be helpful, since you can reproduce > > > the problem, to insert a debugging printk which fires when > > > bh->b_blocknr != pblock before the BUG_ON, and have it print the > > > b_blocknr and pblock values. > > bh->b_blocknr=100346 > > pblock=66797 > > > > Bisecting results so far, > > git bisect start > > # good: [a937536b868b8369b98967929045f1df54234323] Linux 3.9-rc3 > > git bisect good a937536b868b8369b98967929045f1df54234323 > > # bad: [9064171268d838b8f283fe111ef086b9479d059a] Merge tag 'for-linus' of > > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes > > git bisect bad 9064171268d838b8f283fe111ef086b9479d059a > > # bad: [38d78e587d4960d0db94add518d27ee74bad2301] mqueue: sys_mq_open: do > > not call mnt_drop_write() if read-only > > git bisect bad 38d78e587d4960d0db94add518d27ee74bad2301 > > # good: [e7489622d3603b7d161b484dcd340d9f678b0c7a] Merge tag 'arm64-fixes' > > of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 > > git bisect good e7489622d3603b7d161b484dcd340d9f678b0c7a > > # good: [172a271b5e090da7468c66b9ccbcdb3d929eed75] Merge branch 'drm-fixes' > > of git://people.freedesktop.org/~airlied/linux > > git bisect good 172a271b5e090da7468c66b9ccbcdb3d929eed75 > > # good: [0a7e453103b9718d357688b83bb968ee108cc874] Merge branch 'next' of > > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux > > git bisect good 0a7e453103b9718d357688b83bb968ee108cc874 > > # bad: [0e401101db49959f5783f6ee9e676124b5a183ac] ext4: fix memory leakage > > in mext_check_coverage > > git bisect bad 0e401101db49959f5783f6ee9e676124b5a183ac > > CAI Qian > > > > > > Thanks, > > > > > > - Ted > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > -- 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] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! 2013-04-01 6:30 ` CAI Qian @ 2013-04-01 6:56 ` Dmitry Monakhov -1 siblings, 0 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-01 6:56 UTC (permalink / raw) To: CAI Qian; +Cc: Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 On Mon, 1 Apr 2013 02:30:47 -0400 (EDT), CAI Qian <caiqian@redhat.com> wrote: > > > ----- Original Message ----- > > From: "Dmitry Monakhov" <dmonakhov@openvz.org> > > To: "CAI Qian" <caiqian@redhat.com>, "Theodore Ts'o" <tytso@mit.edu> > > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" > > <sbest@redhat.com>, linux-ext4@vger.kernel.org > > Sent: Monday, April 1, 2013 2:07:35 PM > > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > > > On Fri, 29 Mar 2013 05:27:02 -0400 (EDT), CAI Qian <caiqian@redhat.com> > > wrote: > > > > > I've spent a half of weekend by trying to create s390x guest image, > > without any success. Can you please share it. > Well, do you have something like IBM system-Z? > http://en.wikipedia.org/wiki/IBM_System_z10 > > Also can be reproduced on system-p, > http://en.wikipedia.org/wiki/IBM_System_p > Ohh... So you are lucky user of this black rocks and you are the only person who can help to reproduce the issue. BTW: Have you run kernel with the patch i've sent you? > Never seen it on x86 so far though. > CAI Qian > > > > > > ----- Original Message ----- > > > > From: "Theodore Ts'o" <tytso@mit.edu> > > > > To: "CAI Qian" <caiqian@redhat.com> > > > > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" > > > > <linux-s390@vger.kernel.org>, "Steve Best" > > > > <sbest@redhat.com>, linux-ext4@vger.kernel.org > > > > Sent: Thursday, March 28, 2013 8:05:17 PM > > > > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > > > > > > > On Thu, Mar 28, 2013 at 02:40:33AM -0400, CAI Qian wrote: > > > > > System hung when running xfstests-dev 013 test case on an s390x > > > > > guest. Never saw > > > > > this on 3.9-rc3 before but need to double-check. Any idea? > > > > > > > > > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > > > > > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > > > > > > > > thanks for the report. What kernel version did this come from? Was > > > > it 3.9-rc4? (line 1591 for 3.9-rc3 doesn't contain a BUG_ON). > > > Yes, the lastest mainline. > > > > > > > > If it is indeed 3.9-rc4, it would be helpful, since you can reproduce > > > > the problem, to insert a debugging printk which fires when > > > > bh->b_blocknr != pblock before the BUG_ON, and have it print the > > > > b_blocknr and pblock values. > > > bh->b_blocknr=100346 > > > pblock=66797 > > > > > > Bisecting results so far, > > > git bisect start > > > # good: [a937536b868b8369b98967929045f1df54234323] Linux 3.9-rc3 > > > git bisect good a937536b868b8369b98967929045f1df54234323 > > > # bad: [9064171268d838b8f283fe111ef086b9479d059a] Merge tag 'for-linus' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes > > > git bisect bad 9064171268d838b8f283fe111ef086b9479d059a > > > # bad: [38d78e587d4960d0db94add518d27ee74bad2301] mqueue: sys_mq_open: do > > > not call mnt_drop_write() if read-only > > > git bisect bad 38d78e587d4960d0db94add518d27ee74bad2301 > > > # good: [e7489622d3603b7d161b484dcd340d9f678b0c7a] Merge tag 'arm64-fixes' > > > of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 > > > git bisect good e7489622d3603b7d161b484dcd340d9f678b0c7a > > > # good: [172a271b5e090da7468c66b9ccbcdb3d929eed75] Merge branch 'drm-fixes' > > > of git://people.freedesktop.org/~airlied/linux > > > git bisect good 172a271b5e090da7468c66b9ccbcdb3d929eed75 > > > # good: [0a7e453103b9718d357688b83bb968ee108cc874] Merge branch 'next' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux > > > git bisect good 0a7e453103b9718d357688b83bb968ee108cc874 > > > # bad: [0e401101db49959f5783f6ee9e676124b5a183ac] ext4: fix memory leakage > > > in mext_check_coverage > > > git bisect bad 0e401101db49959f5783f6ee9e676124b5a183ac > > > CAI Qian > > > > > > > > Thanks, > > > > > > > > - Ted > > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! @ 2013-04-01 6:56 ` Dmitry Monakhov 0 siblings, 0 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-01 6:56 UTC (permalink / raw) To: CAI Qian; +Cc: Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 On Mon, 1 Apr 2013 02:30:47 -0400 (EDT), CAI Qian <caiqian@redhat.com> wrote: > > > ----- Original Message ----- > > From: "Dmitry Monakhov" <dmonakhov@openvz.org> > > To: "CAI Qian" <caiqian@redhat.com>, "Theodore Ts'o" <tytso@mit.edu> > > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" > > <sbest@redhat.com>, linux-ext4@vger.kernel.org > > Sent: Monday, April 1, 2013 2:07:35 PM > > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > > > On Fri, 29 Mar 2013 05:27:02 -0400 (EDT), CAI Qian <caiqian@redhat.com> > > wrote: > > > > > I've spent a half of weekend by trying to create s390x guest image, > > without any success. Can you please share it. > Well, do you have something like IBM system-Z? > http://en.wikipedia.org/wiki/IBM_System_z10 > > Also can be reproduced on system-p, > http://en.wikipedia.org/wiki/IBM_System_p > Ohh... So you are lucky user of this black rocks and you are the only person who can help to reproduce the issue. BTW: Have you run kernel with the patch i've sent you? > Never seen it on x86 so far though. > CAI Qian > > > > > > ----- Original Message ----- > > > > From: "Theodore Ts'o" <tytso@mit.edu> > > > > To: "CAI Qian" <caiqian@redhat.com> > > > > Cc: "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" > > > > <linux-s390@vger.kernel.org>, "Steve Best" > > > > <sbest@redhat.com>, linux-ext4@vger.kernel.org > > > > Sent: Thursday, March 28, 2013 8:05:17 PM > > > > Subject: Re: s390x: kernel BUG at fs/ext4/inode.c:1591! > > > > > > > > On Thu, Mar 28, 2013 at 02:40:33AM -0400, CAI Qian wrote: > > > > > System hung when running xfstests-dev 013 test case on an s390x > > > > > guest. Never saw > > > > > this on 3.9-rc3 before but need to double-check. Any idea? > > > > > > > > > > Ý 1113.795759¨ ------------Ý cut here ¨------------ > > > > > Ý 1113.795771¨ kernel BUG at fs/ext4/inode.c:1591! > > > > > > > > thanks for the report. What kernel version did this come from? Was > > > > it 3.9-rc4? (line 1591 for 3.9-rc3 doesn't contain a BUG_ON). > > > Yes, the lastest mainline. > > > > > > > > If it is indeed 3.9-rc4, it would be helpful, since you can reproduce > > > > the problem, to insert a debugging printk which fires when > > > > bh->b_blocknr != pblock before the BUG_ON, and have it print the > > > > b_blocknr and pblock values. > > > bh->b_blocknr=100346 > > > pblock=66797 > > > > > > Bisecting results so far, > > > git bisect start > > > # good: [a937536b868b8369b98967929045f1df54234323] Linux 3.9-rc3 > > > git bisect good a937536b868b8369b98967929045f1df54234323 > > > # bad: [9064171268d838b8f283fe111ef086b9479d059a] Merge tag 'for-linus' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes > > > git bisect bad 9064171268d838b8f283fe111ef086b9479d059a > > > # bad: [38d78e587d4960d0db94add518d27ee74bad2301] mqueue: sys_mq_open: do > > > not call mnt_drop_write() if read-only > > > git bisect bad 38d78e587d4960d0db94add518d27ee74bad2301 > > > # good: [e7489622d3603b7d161b484dcd340d9f678b0c7a] Merge tag 'arm64-fixes' > > > of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 > > > git bisect good e7489622d3603b7d161b484dcd340d9f678b0c7a > > > # good: [172a271b5e090da7468c66b9ccbcdb3d929eed75] Merge branch 'drm-fixes' > > > of git://people.freedesktop.org/~airlied/linux > > > git bisect good 172a271b5e090da7468c66b9ccbcdb3d929eed75 > > > # good: [0a7e453103b9718d357688b83bb968ee108cc874] Merge branch 'next' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux > > > git bisect good 0a7e453103b9718d357688b83bb968ee108cc874 > > > # bad: [0e401101db49959f5783f6ee9e676124b5a183ac] ext4: fix memory leakage > > > in mext_check_coverage > > > git bisect bad 0e401101db49959f5783f6ee9e676124b5a183ac > > > CAI Qian > > > > > > > > Thanks, > > > > > > > > - Ted > > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > -- 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] 42+ messages in thread
* bisected! (WAS Re: s390x: kernel BUG at fs/ext4/inode.c:1591!) 2013-04-01 6:56 ` Dmitry Monakhov (?) @ 2013-04-02 4:06 ` CAI Qian [not found] ` <alpine.DEB.2.10.1304012249440.5874@trent.utfs.org> 2013-04-02 10:01 ` bisected! (WAS Re: s390x: kernel BUG at fs/ext4/inode.c:1591!) Dmitry Monakhov -1 siblings, 2 replies; 42+ messages in thread From: CAI Qian @ 2013-04-02 4:06 UTC (permalink / raw) To: Dmitry Monakhov Cc: Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 Bisect indicated this is the culprit, 0e401101db49959f5783f6ee9e676124b5a183ac ext4: fix memory leakage in mext_check_coverage This following with Dmitry's debug patch applied, CAI Qian Ý 101.408610¨ ES cache assertation failed for inode: 753 es_cached ex Ý56/5/744 81/20¨ != found ex Ý56/5/3396400/0¨ retval 0 flags 5 Ý 209.858899¨ ES cache assertation failed for inode: 384 es_cached ex Ý57/7/332 82/20¨ != found ex Ý57/7/3396400/0¨ retval 0 flags 5 Ý 209.860656¨ ES cache assertation failed for inode: 384 es_cached ex Ý25/1/332 50/20¨ != found ex Ý25/1/0/0¨ retval 0 flags 0 Ý 209.893587¨ ES cache assertation failed for inode: 384 es_cached ex Ý22/1/332 47/20¨ != found ex Ý22/1/34838/1000¨ retval 1 flags 0 Ý 209.913482¨ ES cache assertation failed for inode: 384 es_cached ex Ý27/1/329 40/20¨ != found ex Ý27/1/0/0¨ retval 0 flags 0 Ý 209.919950¨ ES cache assertation failed for inode: 384 es_cached ex Ý59/5/338 48/20¨ != found ex Ý59/5/3396400/0¨ retval 0 flags 5 Ý 209.931856¨ ES cache assertation failed for inode: 384 es_cached ex Ý7/1/3292 0/20¨ != found ex Ý7/1/35879/20¨ retval 1 flags 43 Ý 209.969282¨ ES cache assertation failed for inode: 384 es_cached ex Ý35/1/361 97/20¨ != found ex Ý35/1/36197/1000¨ retval 1 flags 0 Ý 209.969290¨ ES cache assertation failed for inode: 384 es_cached ex Ý48/1/362 10/20¨ != found ex Ý48/1/0/0¨ retval 0 flags 0 Ý 209.980724¨ ES cache assertation failed for inode: 384 es_cached ex Ý13/4/334 89/20¨ != found ex Ý13/4/2161372/0¨ retval 0 flags 5 Ý 209.980744¨ ES cache assertation failed for inode: 384 es_cached ex Ý61/3/335 37/20¨ != found ex Ý61/3/3396400/0¨ retval 0 flags 5 Ý 209.983848¨ ES cache assertation failed for inode: 384 es_cached ex Ý44/2/335 20/20¨ != found ex Ý44/2/36216/20¨ retval 2 flags 43 Ý 210.020041¨ ES cache assertation failed for inode: 384 es_cached ex Ý61/3/341 91/20¨ != found ex Ý61/3/3396400/0¨ retval 0 flags 5 Ý 210.050100¨ ES cache assertation failed for inode: 384 es_cached ex Ý22/11/34 565/20¨ != found ex Ý22/11/3396400/0¨ retval 0 flags 5 Ý 210.053271¨ ES cache assertation failed for inode: 384 es_cached ex Ý15/1/334 90/20¨ != found ex Ý15/1/33579/1000¨ retval 1 flags 1 Ý 210.053275¨ mpage_da_submit_io failed block=33490 != b_blocknr=33579 Ý 210.053277¨ ino:384 lbkl:15, b_state=0x00001023, b_size=4096 Ý 210.053320¨ ------------Ý cut here ¨------------ Ý 210.053323¨ kernel BUG at fs/ext4/inode.c:1639! Ý 210.053402¨ illegal operation: 0001 Ý#1¨ SMP Ý 210.053405¨ Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipt able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defra g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tab les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod dasd_eck d_mod lcs dasd_mod qeth ctcm qdio ccwgroup fsm dm_mirror dm_region_hash dm_log d m_mod Ý 210.053434¨ CPU: 0 Not tainted 3.8.0-rc3+ #16 Ý 210.053436¨ Process fsx (pid: 20565, task: 000000002c358000, ksp: 000000002c0 8f480) Ý 210.053439¨ Krnl PSW : 0704f00180000000 00000000003033e8 (mpage_da_submit_io 0x3d4/0x408) Ý 210.053450¨ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 EA: 3 Krnl GPRS: 0000000000000015 0000000000000001 0000000000000030 00000000031b4508 Ý 210.053455¨ 00000000003033e4 0000000000000000 0000000000001000 000 7ffff00001000 Ý 210.053457¨ 000000002c08fa98 000003d100a8c6c0 000000002c08fb68 000 000000000000f Ý 210.053460¨ 00000000000082d2 000000002204d068 00000000003033e4 000 000002c08f970 Ý 210.053473¨ Krnl Code: 00000000003033d8: c02000215447 larl %r2,72dc 66 00000000003033de: c0e50016788f brasl %r14,5d24fc #00000000003033e4: a7f40001 brc 15,3033e6 >00000000003033e8: a7f40001 brc 15,3033ea 00000000003033ec: a7f40001 brc 15,3033ee 00000000003033f0: 4120f0e8 la %r2,232(%r15) 00000000003033f4: a7180000 lhi %r1,0 00000000003033f8: 5010f0d8 st %r1,216(%r15) Ý 210.053497¨ Call Trace: Ý 210.053498¨ (Ý<00000000003033e4>¨ mpage_da_submit_io+0x3d0/0x408) Ý 210.053501¨ Ý<0000000000309a48>¨ mpage_da_map_and_submit+0x150/0x41c Ý 210.053505¨ Ý<000000000030a212>¨ write_cache_pages_da+0x4fe/0x530 Ý 210.053509¨ Ý<000000000030a584>¨ ext4_da_writepages+0x340/0x628 Ý 210.053512¨ Ý<00000000002024d2>¨ __filemap_fdatawrite_range+0x6e/0x7c Ý 210.053518¨ Ý<00000000002025fc>¨ filemap_write_and_wait_range+0x54/0x8c Ý 210.053521¨ Ý<00000000002fe0f8>¨ ext4_sync_file+0x7c/0x3d8 Ý 210.053524¨ Ý<000000000023c932>¨ SyS_msync+0x14e/0x1d8 Ý 210.053528¨ Ý<00000000005de66e>¨ sysc_tracego+0x14/0x1a Ý 210.053533¨ Ý<000003fffd0e1240>¨ 0x3fffd0e1240 Ý 210.053536¨ Last Breaking-Event-Address: Ý 210.053537¨ Ý<00000000003033e4>¨ mpage_da_submit_io+0x3d0/0x408 Ý 210.053540¨ Ý 210.053542¨ ---Ý end trace f387176e9fcb98d0 ¨--- Ý 210.053546¨ ------------Ý cut here ¨------------ Ý 210.053548¨ WARNING: at kernel/exit.c:713 Ý 210.053550¨ Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipt able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defra g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tab les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod dasd_eck d_mod lcs dasd_mod qeth ctcm qdio ccwgroup fsm dm_mirror dm_region_hash dm_log d m_mod Ý 210.053571¨ CPU: 0 Tainted: G D 3.8.0-rc3+ #16 ^ permalink raw reply [flat|nested] 42+ messages in thread
[parent not found: <alpine.DEB.2.10.1304012249440.5874@trent.utfs.org>]
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) [not found] ` <alpine.DEB.2.10.1304012249440.5874@trent.utfs.org> @ 2013-04-02 9:47 ` Dmitry Monakhov 2013-04-02 12:33 ` Zheng Liu ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-02 9:47 UTC (permalink / raw) To: Christian Kujau, CAI Qian Cc: Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 [-- Attachment #1: Type: text/plain, Size: 2306 bytes --] On Mon, 1 Apr 2013 23:15:07 -0700 (PDT), Christian Kujau <lists@nerdbynature.de> wrote: > Hi, > > my machine (PowerBook G4) just crashed and the only thing netconsole was > able to transmit was: > > ------------[ cut here ]------------ > kernel BUG at /usr/local/src/linux-git/fs/ext4/inode.c:1591! > > But (unfortunately) nothing more. I have no clear way to reproduce this, > but I have some kind of a (longish) backstory to this, see below. The > system is running 3.9-rc4, its .config and dmesg: > > http://nerdbynature.de/bits/3.9.0-rc1/config.gz (oldconfig'ed to -rc4) > http://nerdbynature.de/bits/3.9.0-rc1/dmesg.txt (w/o the calltrace at the end) > > > I was having trouble all day downloading a file via bittorrent to an > ext4 filesystem. It came always back as corrupted, though I won't be able > to point out the corruption, as don't know the contents of the source > file. The ext4 filesystem sits on top of a dm-crypt LUKS device: > > /dev/mapper/wdc0 on /mnt/data type ext4 (rw,nosuid,nodev,noexec,relatime,data=ordered) > > While looking around as to why the file would be corrupt, the internet > suggested "bad memory" or "bad disk" or "kernel bugs". I have dismissed > the first two, as the system is rock-stable otherwise and dmesg has no > kernel messages suggesting disk or filesystem problems. Unfortunately it is like a regression which we missed due to s390x and ppc is not well tested. > > The file in question is ~800 MB in size. Not getting any further on a > solution to my corrupted file, I decided to download a 4.3GB Fedora > installation image via bittorrent to the same filesystem and that's when > the machine crashed, leaving only the single BUG message as a hint. Ohh that is sad. Unfortunately I can't reproduce this on my own environment. I have power mac pro G5 but w/o graphics card, so i cant install linux on it. If you know how to do that w/o monitor please let me know. So you just do bunch of writes/mmap to fallocated area. The only guess I have is that some bug in extent status tree Please run test with a patch which was posted here: http://marc.info/?l=linux-kernel&m=136455173926544&w=2 This patch enable sanity checks for extent_status tree. Also please try following patch. It voluntary disable es_lookup functionality. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: disable-es_lookup_extent.patch --] [-- Type: text/x-patch, Size: 433 bytes --] diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index fe3337a..95d27cd 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -689,6 +689,7 @@ int ext4_es_lookup_extent(struct inode *inode, ext4_lblk_t lblk, trace_ext4_es_lookup_extent_enter(inode, lblk); es_debug("lookup extent in block %u\n", lblk); + return 0; tree = &EXT4_I(inode)->i_es_tree; read_lock(&EXT4_I(inode)->i_es_lock); [-- Attachment #3: Type: text/plain, Size: 340 bytes --] > > The system is back now, e2fsck-1.42.5 came back with no errors. > > Thanks for reading, > Christian. > > PS: somewhat off-topic, but: is there a way to have BUG_ON print only > fs/ext4/inode.c:1591! instead of the full pathname? Is there are > config option for this? > -- > BOFH excuse #339: > > manager in the cable duct ^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) 2013-04-02 9:47 ` s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) Dmitry Monakhov @ 2013-04-02 12:33 ` Zheng Liu [not found] ` <alpine.DEB.2.10.1304021202100.13746@trent.utfs.org> [not found] ` <alpine.DEB.2.10.1304020955280.13746@trent.utfs.org> [not found] ` <alpine.DEB.2.10.1304021430480.13746@trent.utfs.org> 2 siblings, 1 reply; 42+ messages in thread From: Zheng Liu @ 2013-04-02 12:33 UTC (permalink / raw) To: Dmitry Monakhov Cc: Christian Kujau, CAI Qian, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 On Tue, Apr 02, 2013 at 01:47:44PM +0400, Dmitry Monakhov wrote: > On Mon, 1 Apr 2013 23:15:07 -0700 (PDT), Christian Kujau <lists@nerdbynature.de> wrote: > > Hi, > > > > my machine (PowerBook G4) just crashed and the only thing netconsole was > > able to transmit was: > > > > ------------[ cut here ]------------ > > kernel BUG at /usr/local/src/linux-git/fs/ext4/inode.c:1591! > > > > But (unfortunately) nothing more. I have no clear way to reproduce this, > > but I have some kind of a (longish) backstory to this, see below. The > > system is running 3.9-rc4, its .config and dmesg: > > > > http://nerdbynature.de/bits/3.9.0-rc1/config.gz (oldconfig'ed to -rc4) > > http://nerdbynature.de/bits/3.9.0-rc1/dmesg.txt (w/o the calltrace at the end) > > > > > > I was having trouble all day downloading a file via bittorrent to an > > ext4 filesystem. It looks like the same problem [1]. But it should have been fixed in 3.9-rc4. Frankly, I think the root cause is es_cache. Sorry, it hasn't been well tested. 1. http://www.serverphorums.com/read.php?12,667656 Could you please revert your tree to this commit (3a225670), and try again. I want to make sure that the regression won't be fixed until now or it is introduced after this commit. Thanks in advance, - Zheng ^ permalink raw reply [flat|nested] 42+ messages in thread
[parent not found: <alpine.DEB.2.10.1304021202100.13746@trent.utfs.org>]
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) [not found] ` <alpine.DEB.2.10.1304021202100.13746@trent.utfs.org> @ 2013-04-02 19:49 ` Dmitry Monakhov 0 siblings, 0 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-02 19:49 UTC (permalink / raw) To: Christian Kujau, Zheng Liu Cc: CAI Qian, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 [-- Attachment #1: Type: text/plain, Size: 891 bytes --] On Tue, 2 Apr 2013 12:07:37 -0700 (PDT), Christian Kujau <lists@nerdbynature.de> wrote: > On Tue, 2 Apr 2013 at 20:33, Zheng Liu wrote: > > Could you please revert your tree to this commit (3a225670), and try > > again. I want to make sure that the regression won't be fixed until now > > or it is introduced after this commit. > > I have git-revert'ed this commit and the same BUG_ON was triggered again. > I could not bring "fsstress" to trigger this but resuming this 4.3 GB > Fedora DVD image via bittorrent made the machine crash after a couple of > minutes. > > Sadly the only message netconsole is able to catch is this single line > from the subject above, but I'll try to apply the proposed patches[0] and > see if it helps anything. Ok if netconsole can't log in case of BUG_ON then we just skip panic :) Please use following patch instead of enable_ES_AGGRESSIVE_TEST.diff [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-enable-ES_AGGRESSIVE_TEST-V2.patch --] [-- Type: text/x-patch, Size: 2089 bytes --] >From e802d032225a74156f8256467aa64535369ae45c Mon Sep 17 00:00:00 2001 From: Dmitry Monakhov <dmonakhov@openvz.org> Date: Tue, 2 Apr 2013 23:33:16 +0400 Subject: [PATCH] enable ES_AGGRESSIVE_TEST V2 Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org> --- fs/ext4/extents_status.h | 2 +- fs/ext4/inode.c | 17 +++++++++++++++-- 2 files changed, 16 insertions(+), 3 deletions(-) diff --git a/fs/ext4/extents_status.h b/fs/ext4/extents_status.h index d8e2d4d..70233a6 100644 --- a/fs/ext4/extents_status.h +++ b/fs/ext4/extents_status.h @@ -24,7 +24,7 @@ * With ES_AGGRESSIVE_TEST defined, the result of es caching will be * checked with old map_block's result. */ -#define ES_AGGRESSIVE_TEST__ +#define ES_AGGRESSIVE_TEST /* * These flags live in the high bits of extent_status.es_pblk diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 840a23e..7712aff 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1546,7 +1546,18 @@ static int mpage_da_submit_io(struct mpage_da_data *mpd, } if (buffer_unwritten(bh) || buffer_mapped(bh)) - BUG_ON(bh->b_blocknr != pblock); + if (bh->b_blocknr != pblock) { + printk(KERN_ERR "mpage_da_submit_io failed" + " block=%llu != b_blocknr=%llu\n", + (unsigned long long)pblock, + (unsigned long long)bh->b_blocknr); + printk(KERN_ERR "ino:%ld lbkl:%lu, " + "b_state=0x%08lx, b_size=%zu\n", + inode->i_ino, cur_logical, + bh->b_state, bh->b_size); + WARN_ON(1); + goto skip_page; + } if (map->m_flags & EXT4_MAP_UNINIT) set_buffer_uninit(bh); clear_buffer_unwritten(bh); @@ -1556,8 +1567,10 @@ static int mpage_da_submit_io(struct mpage_da_data *mpd, * skip page if block allocation undone and * block is dirty */ - if (ext4_bh_delay_or_unwritten(NULL, bh)) + if (ext4_bh_delay_or_unwritten(NULL, bh)) { + skip_page: skip_page = 1; + } bh = bh->b_this_page; block_start += bh->b_size; cur_logical++; -- 1.7.1 [-- Attachment #3: Type: text/plain, Size: 523 bytes --] So once you hit the bug it will print a lot of warnings and try to pretend what nothing is happens. So my predictions is follows: 1) with enable_ES_AGGRESSIVE_TEST-V2.diff patch you will see a lot of warnings 2) with enable_ES_AGGRESSIVE_TEST-V2.diff and http://nerdbynature.de/bits/3.9.0-rc4/ext4/disable-es_lookup_extent.patch Issue probably will go away (will be hidden) > > Thanks, > Christian. > > [0] http://nerdbynature.de/bits/3.9.0-rc4/ext4/ > -- > BOFH excuse #344: > > Network failure - call NBC ^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) @ 2013-04-02 19:49 ` Dmitry Monakhov 0 siblings, 0 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-02 19:49 UTC (permalink / raw) To: Christian Kujau, Zheng Liu Cc: CAI Qian, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 [-- Attachment #1: Type: text/plain, Size: 891 bytes --] On Tue, 2 Apr 2013 12:07:37 -0700 (PDT), Christian Kujau <lists@nerdbynature.de> wrote: > On Tue, 2 Apr 2013 at 20:33, Zheng Liu wrote: > > Could you please revert your tree to this commit (3a225670), and try > > again. I want to make sure that the regression won't be fixed until now > > or it is introduced after this commit. > > I have git-revert'ed this commit and the same BUG_ON was triggered again. > I could not bring "fsstress" to trigger this but resuming this 4.3 GB > Fedora DVD image via bittorrent made the machine crash after a couple of > minutes. > > Sadly the only message netconsole is able to catch is this single line > from the subject above, but I'll try to apply the proposed patches[0] and > see if it helps anything. Ok if netconsole can't log in case of BUG_ON then we just skip panic :) Please use following patch instead of enable_ES_AGGRESSIVE_TEST.diff [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-enable-ES_AGGRESSIVE_TEST-V2.patch --] [-- Type: text/x-patch, Size: 2088 bytes --] From e802d032225a74156f8256467aa64535369ae45c Mon Sep 17 00:00:00 2001 From: Dmitry Monakhov <dmonakhov@openvz.org> Date: Tue, 2 Apr 2013 23:33:16 +0400 Subject: [PATCH] enable ES_AGGRESSIVE_TEST V2 Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org> --- fs/ext4/extents_status.h | 2 +- fs/ext4/inode.c | 17 +++++++++++++++-- 2 files changed, 16 insertions(+), 3 deletions(-) diff --git a/fs/ext4/extents_status.h b/fs/ext4/extents_status.h index d8e2d4d..70233a6 100644 --- a/fs/ext4/extents_status.h +++ b/fs/ext4/extents_status.h @@ -24,7 +24,7 @@ * With ES_AGGRESSIVE_TEST defined, the result of es caching will be * checked with old map_block's result. */ -#define ES_AGGRESSIVE_TEST__ +#define ES_AGGRESSIVE_TEST /* * These flags live in the high bits of extent_status.es_pblk diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 840a23e..7712aff 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1546,7 +1546,18 @@ static int mpage_da_submit_io(struct mpage_da_data *mpd, } if (buffer_unwritten(bh) || buffer_mapped(bh)) - BUG_ON(bh->b_blocknr != pblock); + if (bh->b_blocknr != pblock) { + printk(KERN_ERR "mpage_da_submit_io failed" + " block=%llu != b_blocknr=%llu\n", + (unsigned long long)pblock, + (unsigned long long)bh->b_blocknr); + printk(KERN_ERR "ino:%ld lbkl:%lu, " + "b_state=0x%08lx, b_size=%zu\n", + inode->i_ino, cur_logical, + bh->b_state, bh->b_size); + WARN_ON(1); + goto skip_page; + } if (map->m_flags & EXT4_MAP_UNINIT) set_buffer_uninit(bh); clear_buffer_unwritten(bh); @@ -1556,8 +1567,10 @@ static int mpage_da_submit_io(struct mpage_da_data *mpd, * skip page if block allocation undone and * block is dirty */ - if (ext4_bh_delay_or_unwritten(NULL, bh)) + if (ext4_bh_delay_or_unwritten(NULL, bh)) { + skip_page: skip_page = 1; + } bh = bh->b_this_page; block_start += bh->b_size; cur_logical++; -- 1.7.1 [-- Attachment #3: Type: text/plain, Size: 523 bytes --] So once you hit the bug it will print a lot of warnings and try to pretend what nothing is happens. So my predictions is follows: 1) with enable_ES_AGGRESSIVE_TEST-V2.diff patch you will see a lot of warnings 2) with enable_ES_AGGRESSIVE_TEST-V2.diff and http://nerdbynature.de/bits/3.9.0-rc4/ext4/disable-es_lookup_extent.patch Issue probably will go away (will be hidden) > > Thanks, > Christian. > > [0] http://nerdbynature.de/bits/3.9.0-rc4/ext4/ > -- > BOFH excuse #344: > > Network failure - call NBC ^ permalink raw reply related [flat|nested] 42+ messages in thread
[parent not found: <alpine.DEB.2.10.1304020955280.13746@trent.utfs.org>]
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) [not found] ` <alpine.DEB.2.10.1304020955280.13746@trent.utfs.org> @ 2013-04-02 17:19 ` Dmitry Monakhov 0 siblings, 0 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-02 17:19 UTC (permalink / raw) To: Christian Kujau Cc: CAI Qian, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 On Tue, 2 Apr 2013 09:58:46 -0700 (PDT), Christian Kujau <lists@nerdbynature.de> wrote: > On Tue, 2 Apr 2013 at 13:47, Dmitry Monakhov wrote: > > Unfortunately it is like a regression which we missed > > due to s390x and ppc is not well tested. > > :-( > > > Ohh that is sad. Unfortunately I can't reproduce this on my own > > environment. I have power mac pro G5 but w/o graphics card, so i cant > > install linux on it. If you know how to do that w/o monitor please let > > me know. > > Hm, w/o a graphics card..the only way to install any OS would be via a > serial line, I assume. I've tried to use qemu but I can not even boot the kernel: Preparing to boot Linux version 3.9.0-rc4 (root@dbuild4.qa.sw.ru) (gcc version 4.4.5 (Debian 4.4.5-8) ) #6 Tue Apr 2 19:12:42 MSK 2013 Detected machine type: 00000400 command line: console=ttyS0,9600 console=tty0 memory layout at init: memory_limit : 00000000 (16 MB aligned) alloc_bottom : 0164d000 alloc_top : 20000000 alloc_top_hi : 20000000 rmo_top : 20000000 ram_top : 20000000 found display : /pci@80000000/QEMU,VGA@1, opening... done copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x0164e000 -> 0x0164e4d7 Device tree struct 0x0164f000 -> 0x01651000 Calling quiesce... returning from prom_init Trying to write invalid spr 1015 3f7 at c0008bc0 Can anybody help me with simple thing Build and boot kernel via qemu > > > So you just do bunch of writes/mmap to fallocated area. > > The only guess I have is that some bug in extent status tree > > "writes/mmap to fallocated area" - this sounds like the exact thing this > bittorrent client is doing! > > > Please run test with a patch which was posted here: > > http://marc.info/?l=linux-kernel&m=136455173926544&w=2 > > This patch enable sanity checks for extent_status tree. > > Also please try following patch. It voluntary disable es_lookup functionality. > > I'll find a way to reproduce this first and then play around with those patches. Probably all you need is just run fsstress (https://github.com/dmonakhov/xfstests/blob/master/ltp/fsstress.c) And run in like follows: #fsstress -d $YOUR_PATH -p 4 -z -f rmdir=10 -f link=10 -f creat=10 -f mkdir=10 \ -f rename=30 -f stat=30 -f unlink=30 -f truncate=20 -n99999999 > > Thanks for your response, > Christian. > -- > BOFH excuse #415: > > Maintenance window broken ^ permalink raw reply [flat|nested] 42+ messages in thread
[parent not found: <alpine.DEB.2.10.1304021430480.13746@trent.utfs.org>]
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) [not found] ` <alpine.DEB.2.10.1304021430480.13746@trent.utfs.org> @ 2013-04-02 22:05 ` Dmitry Monakhov [not found] ` <alpine.DEB.2.10.1304021611020.13746@trent.utfs.org> 0 siblings, 1 reply; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-02 22:05 UTC (permalink / raw) To: Christian Kujau Cc: CAI Qian, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4, Zheng Liu On Tue, 2 Apr 2013 14:35:29 -0700 (PDT), Christian Kujau <lists@nerdbynature.de> wrote: > On Tue, 2 Apr 2013 at 13:47, Dmitry Monakhov wrote: > > So you just do bunch of writes/mmap to fallocated area. > > The only guess I have is that some bug in extent status tree > > > > Please run test with a patch which was posted here: > > http://marc.info/?l=linux-kernel&m=136455173926544&w=2 > > This patch enable sanity checks for extent_status tree. > > Also please try following patch. It voluntary disable es_lookup functionality. > > I tested your patch below (applied to 3.9-rc4) and now the BUG is gone. > The machine stays up and the corruption of that torrent file is gone too! > > Feel free to add my Tested-by: but I don't know if this will be the final > solution to this issue, no? No. This is just a proof that es_cache is a root of cause. Please drop that patch and collect logs with a kernel which has only 0001-enable-ES_AGGRESSIVE_TEST-V2.patch patch applied This can help us understand what was wrong. From CAI Qian's logs(http://marc.info/?l=linux-ext4&m=136489690730402&w=2) I found that in most cases assertion failed because ec_cache contains BH_Mapped entries, but extent_tree has not data at all Also there is another assertion failure where es_cache {15/1/33490/MAPPED} != extent_tree {15/1/33579/BH_UNWRITTEN} > > Thanks! > Christian. > > diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c> index fe3337a..95d27cd 100644 > --- a/fs/ext4/extents_status.c > +++ b/fs/ext4/extents_status.c > @@ -689,6 +689,7 @@ int ext4_es_lookup_extent(struct inode *inode, ext4_lblk_t lblk, > trace_ext4_es_lookup_extent_enter(inode, lblk); > es_debug("lookup extent in block %u\n", lblk); > > + return 0; > tree = &EXT4_I(inode)->i_es_tree; > read_lock(&EXT4_I(inode)->i_es_lock); > > -- > BOFH excuse #414: > > tachyon emissions overloading the system ^ permalink raw reply [flat|nested] 42+ messages in thread
[parent not found: <alpine.DEB.2.10.1304021611020.13746@trent.utfs.org>]
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) [not found] ` <alpine.DEB.2.10.1304021611020.13746@trent.utfs.org> @ 2013-04-03 8:52 ` Dmitry Monakhov 2013-04-03 9:53 ` Dmitry Monakhov 0 siblings, 1 reply; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-03 8:52 UTC (permalink / raw) To: Christian Kujau Cc: CAI Qian, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4, Zheng Liu [-- Attachment #1: Type: text/plain, Size: 342 bytes --] On Tue, 2 Apr 2013 16:22:41 -0700 (PDT), Christian Kujau <lists@nerdbynature.de> wrote: > On Wed, 3 Apr 2013 at 02:05, Dmitry Monakhov wrote: > > Please drop that patch and collect logs with a kernel which > > has only 0001-enable-ES_AGGRESSIVE_TEST-V2.patch patch applied Ok I have found at least one issue. Please give a try to this patch [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: ext4_zeroout_cpu2disk_fix.patch --] [-- Type: text/x-patch, Size: 504 bytes --] diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 1530cf4..e8460f6 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3272,7 +3272,7 @@ static int ext4_ext_convert_to_initialized(handle_t *handle, if (err) goto out; zero_ex.ee_block = ex->ee_block; - zero_ex.ee_len = ext4_ext_get_actual_len(ex); + zero_ex.ee_len = cpu_to_le16(ext4_ext_get_actual_len(ext)); ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(ex)); err = ext4_ext_get_access(handle, inode, path + depth); [-- Attachment #3: Type: text/plain, Size: 3017 bytes --] > > I've applied (only) 0001-enable-ES_AGGRESSIVE_TEST-V2.patch to 3.9-rc4: > > patching file fs/ext4/extents_status.h > patching file fs/ext4/inode.c > Hunk #1 succeeded at 1588 (offset 42 lines). > Hunk #2 succeeded at 1609 (offset 42 lines). > > And tried to download some images via bittorrent. As expected, lots of > "ES cache assertation failed" were being logged: > > http://nerdbynature.de/bits/3.9.0-rc4/ext4/ > => messages_0001-enable-ES_AGGRESSIVE_TEST-V2.txt.xz > > I've tried to download 3 files, all via bittorrent (so, fallocate & heavy > mmap) > > 1) 8GB Fedora iso, there are also WARNINGs bring triggered, see below. > I decided to cancel the download after some gigabyes. > > 2) A 50 MB Debian iso, this produced just one "ES cache assertation" > message. Download went OK, checksum was correct too. > > 3) A 221 MB Fedora iso, produced a couple of "ES cache assertation" > messages, but no WARNINGs. Download went OK, checksum was correct too. > > It's all in that messages_0001-enable-ES_AGGRESSIVE_TEST-V2.txt.xz file > above. I just e2fsck'ed the ext4 filesystem again (and did so last night), > but no errors were found. > > HTH, > Christian. > > One of the WARNINGs during that 8GB download: > > ino:39190654 lbkl:0, b_state=0x0004b988, b_size=4131 > ------------[ cut here ]------------ > WARNING: at /opt/linux-git/fs/ext4/inode.c:1600 > Modules linked in: md5 ecb nfs i2c_powermac therm_adt746x ecryptfs firewire_sbp2 arc4 b43 usb_storage mac80211 cfg80211 > NIP: c013745c LR: c013745c CTR: c000df9c > REGS: edc479a0 TRAP: 0700 Tainted: G W (3.9.0-rc4-dirty) > MSR: 00029032 <EE,ME,IR,DR,RI> CR: 44028644 XER: 20000000 > TASK = edca9740[4379] 'flush-254:1' THREAD: edc46000 > GPR00: c013745c edc47a50 edca9740 00000034 edca9db0 00000006 00000000 00008000 > GPR08: 00003fb0 00218f23 00000000 c000006e 00000dc9 00000000 00000009 ee18cca0 > GPR16: edc47c78 0000000e 0004b9bf 0004b988 00000000 edc47a84 00001000 e6357540 > GPR24: edc47b78 e6357540 00000000 0004b97f 00000000 0051d188 00000000 0004b988 > NIP [c013745c] mpage_da_submit_io+0x3dc/0x3f0 > LR [c013745c] mpage_da_submit_io+0x3dc/0x3f0 > Call Trace: > [edc47a50] [c013745c] mpage_da_submit_io+0x3dc/0x3f0 (unreliable) > [edc47b30] [c013c9f0] mpage_da_map_and_submit+0x16c/0x5f0 > [edc47bc0] [c013d2e4] write_cache_pages_da+0x470/0x480 > [edc47c70] [c013d554] ext4_da_writepages+0x260/0x49c > [edc47d20] [c00eeea0] __writeback_single_inode+0x34/0x120 > [edc47d40] [c00ef508] writeback_sb_inodes+0x1fc/0x34c > [edc47db0] [c00ef6e4] __writeback_inodes_wb+0x8c/0xd0 > [edc47de0] [c00efa90] wb_writeback+0x1b4/0x1bc > [edc47e20] [c00f06d0] wb_do_writeback+0x1ec/0x1f4 > [edc47e80] [c00f0748] bdi_writeback_thread+0x70/0x140 > [edc47eb0] [c0051c18] kthread+0xa8/0xac > [edc47f40] [c00106cc] ret_from_kernel_thread+0x64/0x6c > --- Exception: 0 at (null) > LR = (null) > Instruction dump: > > -- > BOFH excuse #61: > > not approved by the FCC ^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) 2013-04-03 8:52 ` Dmitry Monakhov @ 2013-04-03 9:53 ` Dmitry Monakhov 2013-04-03 10:22 ` Zheng Liu 2013-04-03 11:02 ` s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) Dmitry Monakhov 0 siblings, 2 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-03 9:53 UTC (permalink / raw) To: Christian Kujau Cc: CAI Qian, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4, Zheng Liu [-- Attachment #1: Type: text/plain, Size: 653 bytes --] On Wed, 03 Apr 2013 12:52:06 +0400, Dmitry Monakhov <dmonakhov@openvz.org> wrote: Non-text part: multipart/mixed > On Tue, 2 Apr 2013 16:22:41 -0700 (PDT), Christian Kujau <lists@nerdbynature.de> wrote: > > On Wed, 3 Apr 2013 at 02:05, Dmitry Monakhov wrote: > > > Please drop that patch and collect logs with a kernel which > > > has only 0001-enable-ES_AGGRESSIVE_TEST-V2.patch patch applied > Ok I have found at least one issue. Yeah.. My college advise me to use sparse in order to spot all cpu_to_ondisk format conversion make C=2 CF="-D__CHECK_ENDIAN__" fs/ext4/ And it spotted a huge amount of issues. Which tell us that we are deeply in shit. [-- Attachment #2: sparse.log --] [-- Type: text/plain, Size: 9235 bytes --] <stdin>:1220:2: warning: #warning syscall kcmp not implemented <stdin>:1223:2: warning: #warning syscall finit_module not implemented fs/ext4/ialloc.c:902:37: warning: symbol 'sbi' shadows an earlier one fs/ext4/ialloc.c:650:29: originally declared here fs/ext4/inode.c:58:17: warning: incorrect type in assignment (different base types) fs/ext4/inode.c:58:17: expected unsigned short [unsigned] [usertype] csum_lo fs/ext4/inode.c:58:17: got restricted __le16 [usertype] l_i_checksum_lo fs/ext4/inode.c:62:25: warning: incorrect type in assignment (different base types) fs/ext4/inode.c:62:25: expected unsigned short [unsigned] [usertype] csum_hi fs/ext4/inode.c:62:25: got restricted __le16 [usertype] i_checksum_hi fs/ext4/inode.c:69:28: warning: incorrect type in assignment (different base types) fs/ext4/inode.c:69:28: expected restricted __le16 [usertype] l_i_checksum_lo fs/ext4/inode.c:69:28: got unsigned short [unsigned] [usertype] csum_lo fs/ext4/inode.c:72:36: warning: incorrect type in assignment (different base types) fs/ext4/inode.c:72:36: expected restricted __le16 [usertype] i_checksum_hi fs/ext4/inode.c:72:36: got unsigned short [unsigned] [usertype] csum_hi include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction fs/ext4/ioctl.c:358:36: warning: symbol 'sb' shadows an earlier one fs/ext4/ioctl.c:26:28: originally declared here fs/ext4/namei.c:2008:36: warning: potentially expensive pointer subtraction fs/ext4/namei.c:423:18: warning: incorrect type in assignment (different base types) fs/ext4/namei.c:423:18: expected unsigned int [unsigned] [usertype] old_csum fs/ext4/namei.c:423:18: got restricted __le32 [usertype] dt_checksum fs/ext4/namei.c:427:24: warning: incorrect type in assignment (different base types) fs/ext4/namei.c:427:24: expected restricted __le32 [usertype] dt_checksum fs/ext4/namei.c:427:24: got unsigned int [unsigned] [usertype] old_csum include/trace/events/ext4.h:1926:1: warning: cast from restricted __le32 include/trace/events/ext4.h:1926:1: warning: incorrect type in assignment (different base types) include/trace/events/ext4.h:1926:1: expected unsigned int [unsigned] [usertype] ee_lblk include/trace/events/ext4.h:1926:1: got restricted __le32 [usertype] <noident> include/trace/events/ext4.h:1926:1: warning: cast from restricted __le32 include/trace/events/ext4.h:1926:1: warning: incorrect type in assignment (different base types) include/trace/events/ext4.h:1926:1: expected unsigned int [unsigned] [usertype] ee_lblk include/trace/events/ext4.h:1926:1: got restricted __le32 [usertype] <noident> fs/ext4/super.c:1957:26: warning: incorrect type in assignment (different base types) fs/ext4/super.c:1957:26: expected unsigned short [unsigned] [usertype] old_csum fs/ext4/super.c:1957:26: got restricted __le16 [usertype] bg_checksum fs/ext4/super.c:1963:34: warning: incorrect type in assignment (different base types) fs/ext4/super.c:1963:34: expected restricted __le16 [usertype] bg_checksum fs/ext4/super.c:1963:34: got unsigned short [unsigned] [usertype] old_csum include/uapi/linux/swab.h:60:16: error: undefined identifier '__builtin_bswap32' include/uapi/linux/swab.h:60:33: error: not a function <noident> fs/ext4/extents.c:3002:48: warning: incorrect type in assignment (different base types) fs/ext4/extents.c:3002:48: expected restricted __le16 [assigned] [usertype] ee_len fs/ext4/extents.c:3002:48: got restricted __be16 [usertype] <noident> fs/ext4/extents.c:3008:48: warning: incorrect type in assignment (different base types) fs/ext4/extents.c:3008:48: expected restricted __le16 [addressable] [assigned] [usertype] ee_len fs/ext4/extents.c:3008:48: got restricted __be16 [usertype] <noident> fs/ext4/extents.c:3015:40: warning: incorrect type in assignment (different base types) fs/ext4/extents.c:3015:40: expected restricted __le16 [addressable] [assigned] [usertype] ee_len fs/ext4/extents.c:3015:40: got restricted __be16 [usertype] <noident> fs/ext4/extents.c:603:28: warning: potentially expensive pointer subtraction fs/ext4/extents.c:671:28: warning: potentially expensive pointer subtraction fs/ext4/extents.c:849:43: warning: potentially expensive pointer subtraction fs/ext4/extents.c:984:47: warning: potentially expensive pointer subtraction fs/ext4/extents.c:1063:50: warning: potentially expensive pointer subtraction fs/ext4/extents.c:1656:52: warning: potentially expensive pointer subtraction fs/ext4/extents.c:1706:32: warning: potentially expensive pointer subtraction fs/ext4/extents.c:1929:43: warning: potentially expensive pointer subtraction fs/ext4/extents.c:2206:55: warning: potentially expensive pointer subtraction fs/ext4/extents.c:2528:72: warning: potentially expensive pointer subtraction fs/ext4/extents.c:2787:36: warning: incorrect type in argument 5 (different base types) fs/ext4/extents.c:2787:36: expected unsigned short [unsigned] eh_entries fs/ext4/extents.c:2787:36: got restricted __le16 [usertype] eh_entries fs/ext4/extents.c:3275:32: warning: incorrect type in assignment (different base types) fs/ext4/extents.c:3275:32: expected restricted __le16 [assigned] [usertype] ee_len fs/ext4/extents.c:3275:32: got restricted __be16 [usertype] <noident> fs/ext4/extents.c:4642:34: warning: cast from restricted __le16 fs/ext4/extents.c:4642:34: warning: incorrect type in argument 1 (different base types) fs/ext4/extents.c:4642:34: expected unsigned short [unsigned] [usertype] val fs/ext4/extents.c:4642:34: got restricted __le16 [usertype] eh_entries fs/ext4/extents.c:4642:34: warning: cast from restricted __le16 fs/ext4/extents.c:4642:34: warning: cast from restricted __le16 fs/ext4/extents.c:4642:34: warning: restricted __be16 degrades to integer fs/ext4/mballoc.c:863:21: warning: symbol 'group' shadows an earlier one fs/ext4/mballoc.c:795:35: originally declared here include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction fs/ext4/mballoc.c:4855:9: warning: context imbalance in 'ext4_trim_extent' - unexpected unlock fs/ext4/move_extent.c:859:29: warning: symbol 'err' shadows an earlier one fs/ext4/move_extent.c:835:16: originally declared here include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction fs/ext4/mmp.c:18:16: warning: incorrect type in return expression (different base types) fs/ext4/mmp.c:18:16: expected unsigned int fs/ext4/mmp.c:18:16: got restricted __le32 [usertype] <noident> fs/ext4/mmp.c:27:19: warning: restricted __le32 degrades to integer fs/ext4/mmp.c:36:27: warning: incorrect type in assignment (different base types) fs/ext4/mmp.c:36:27: expected restricted __le32 [usertype] mmp_checksum fs/ext4/mmp.c:36:27: got unsigned int fs/ext4/indirect.c:579:41: warning: potentially expensive pointer subtraction fs/ext4/indirect.c:592:52: warning: potentially expensive pointer subtraction fs/ext4/indirect.c:1257:68: warning: potentially expensive pointer subtraction fs/ext4/indirect.c:1268:67: warning: potentially expensive pointer subtraction fs/ext4/indirect.c:1275:48: warning: potentially expensive pointer subtraction fs/ext4/indirect.c:1327:52: warning: incorrect type in argument 2 (different base types) fs/ext4/indirect.c:1327:52: expected unsigned long [unsigned] [usertype] block fs/ext4/indirect.c:1327:52: got restricted __le32 [assigned] [usertype] blk fs/ext4/indirect.c:1329:33: warning: incorrect type in argument 4 (different base types) fs/ext4/indirect.c:1329:33: expected unsigned long long [unsigned] [usertype] <noident> fs/ext4/indirect.c:1329:33: got restricted __le32 [assigned] [usertype] blk fs/ext4/xattr.c:127:13: warning: incorrect type in assignment (different base types) fs/ext4/xattr.c:127:13: expected unsigned int [unsigned] [usertype] old fs/ext4/xattr.c:127:13: got restricted __le32 [usertype] h_checksum fs/ext4/xattr.c:129:18: warning: incorrect type in assignment (different base types) fs/ext4/xattr.c:129:18: expected unsigned long [unsigned] [usertype] block_nr fs/ext4/xattr.c:129:18: got restricted __le64 [usertype] <noident> fs/ext4/xattr.c:135:25: warning: incorrect type in assignment (different base types) fs/ext4/xattr.c:135:25: expected restricted __le32 [usertype] h_checksum fs/ext4/xattr.c:135:25: got unsigned int [unsigned] [usertype] old include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction [-- Attachment #3: Type: text/plain, Size: 3795 bytes --] So please give me couple of hours and I'll send you a complete patch. > Please give a try to this patch > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c > index 1530cf4..e8460f6 100644 > --- a/fs/ext4/extents.c > +++ b/fs/ext4/extents.c > @@ -3272,7 +3272,7 @@ static int ext4_ext_convert_to_initialized(handle_t *handle, > if (err) > goto out; > zero_ex.ee_block = ex->ee_block; > - zero_ex.ee_len = ext4_ext_get_actual_len(ex); > + zero_ex.ee_len = cpu_to_le16(ext4_ext_get_actual_len(ext)); > ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(ex)); > > err = ext4_ext_get_access(handle, inode, path + depth); > > > > > I've applied (only) 0001-enable-ES_AGGRESSIVE_TEST-V2.patch to 3.9-rc4: > > > > patching file fs/ext4/extents_status.h > > patching file fs/ext4/inode.c > > Hunk #1 succeeded at 1588 (offset 42 lines). > > Hunk #2 succeeded at 1609 (offset 42 lines). > > > > And tried to download some images via bittorrent. As expected, lots of > > "ES cache assertation failed" were being logged: > > > > http://nerdbynature.de/bits/3.9.0-rc4/ext4/ > > => messages_0001-enable-ES_AGGRESSIVE_TEST-V2.txt.xz > > > > I've tried to download 3 files, all via bittorrent (so, fallocate & heavy > > mmap) > > > > 1) 8GB Fedora iso, there are also WARNINGs bring triggered, see below. > > I decided to cancel the download after some gigabyes. > > > > 2) A 50 MB Debian iso, this produced just one "ES cache assertation" > > message. Download went OK, checksum was correct too. > > > > 3) A 221 MB Fedora iso, produced a couple of "ES cache assertation" > > messages, but no WARNINGs. Download went OK, checksum was correct too. > > > > It's all in that messages_0001-enable-ES_AGGRESSIVE_TEST-V2.txt.xz file > > above. I just e2fsck'ed the ext4 filesystem again (and did so last night), > > but no errors were found. > > > > HTH, > > Christian. > > > > One of the WARNINGs during that 8GB download: > > > > ino:39190654 lbkl:0, b_state=0x0004b988, b_size=4131 > > ------------[ cut here ]------------ > > WARNING: at /opt/linux-git/fs/ext4/inode.c:1600 > > Modules linked in: md5 ecb nfs i2c_powermac therm_adt746x ecryptfs firewire_sbp2 arc4 b43 usb_storage mac80211 cfg80211 > > NIP: c013745c LR: c013745c CTR: c000df9c > > REGS: edc479a0 TRAP: 0700 Tainted: G W (3.9.0-rc4-dirty) > > MSR: 00029032 <EE,ME,IR,DR,RI> CR: 44028644 XER: 20000000 > > TASK = edca9740[4379] 'flush-254:1' THREAD: edc46000 > > GPR00: c013745c edc47a50 edca9740 00000034 edca9db0 00000006 00000000 00008000 > > GPR08: 00003fb0 00218f23 00000000 c000006e 00000dc9 00000000 00000009 ee18cca0 > > GPR16: edc47c78 0000000e 0004b9bf 0004b988 00000000 edc47a84 00001000 e6357540 > > GPR24: edc47b78 e6357540 00000000 0004b97f 00000000 0051d188 00000000 0004b988 > > NIP [c013745c] mpage_da_submit_io+0x3dc/0x3f0 > > LR [c013745c] mpage_da_submit_io+0x3dc/0x3f0 > > Call Trace: > > [edc47a50] [c013745c] mpage_da_submit_io+0x3dc/0x3f0 (unreliable) > > [edc47b30] [c013c9f0] mpage_da_map_and_submit+0x16c/0x5f0 > > [edc47bc0] [c013d2e4] write_cache_pages_da+0x470/0x480 > > [edc47c70] [c013d554] ext4_da_writepages+0x260/0x49c > > [edc47d20] [c00eeea0] __writeback_single_inode+0x34/0x120 > > [edc47d40] [c00ef508] writeback_sb_inodes+0x1fc/0x34c > > [edc47db0] [c00ef6e4] __writeback_inodes_wb+0x8c/0xd0 > > [edc47de0] [c00efa90] wb_writeback+0x1b4/0x1bc > > [edc47e20] [c00f06d0] wb_do_writeback+0x1ec/0x1f4 > > [edc47e80] [c00f0748] bdi_writeback_thread+0x70/0x140 > > [edc47eb0] [c0051c18] kthread+0xa8/0xac > > [edc47f40] [c00106cc] ret_from_kernel_thread+0x64/0x6c > > --- Exception: 0 at (null) > > LR = (null) > > Instruction dump: > > > > -- > > BOFH excuse #61: > > > > not approved by the FCC ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) 2013-04-03 9:53 ` Dmitry Monakhov @ 2013-04-03 10:22 ` Zheng Liu 2013-04-03 12:20 ` [PATCH] ext4: fix a big-endian bug when an extent is zeroed out Theodore Ts'o 2013-04-03 11:02 ` s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) Dmitry Monakhov 1 sibling, 1 reply; 42+ messages in thread From: Zheng Liu @ 2013-04-03 10:22 UTC (permalink / raw) To: Dmitry Monakhov Cc: Christian Kujau, CAI Qian, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 On Wed, Apr 03, 2013 at 01:53:49PM +0400, Dmitry Monakhov wrote: > On Wed, 03 Apr 2013 12:52:06 +0400, Dmitry Monakhov <dmonakhov@openvz.org> wrote: > Non-text part: multipart/mixed > > On Tue, 2 Apr 2013 16:22:41 -0700 (PDT), Christian Kujau <lists@nerdbynature.de> wrote: > > > On Wed, 3 Apr 2013 at 02:05, Dmitry Monakhov wrote: > > > > Please drop that patch and collect logs with a kernel which > > > > has only 0001-enable-ES_AGGRESSIVE_TEST-V2.patch patch applied > > Ok I have found at least one issue. > Yeah.. My college advise me to use sparse in order to spot all > cpu_to_ondisk format conversion > make C=2 CF="-D__CHECK_ENDIAN__" fs/ext4/ > And it spotted a huge amount of issues. Which tell us that we are deeply > in shit. Yes, My college also suggest me that we should use sparse to check this problem. I think the following patch could fix this bug. Regards, - Zheng Subject: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out From: Zheng Liu <wenqing.lz@taobao.com> When an extent was zeroed out, we forgot to do convert from cpu to le16. It could make us hit a BUG_ON when we try to write dirty pages out. So fix it. Signed-off-by: Zheng Liu <wenqing.lz@taobao.com> --- fs/ext4/extents.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index e4a6844..2352467 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -2999,20 +2999,23 @@ static int ext4_split_extent_at(handle_t *handle, if (split_flag & EXT4_EXT_DATA_VALID1) { err = ext4_ext_zeroout(inode, ex2); zero_ex.ee_block = ex2->ee_block; - zero_ex.ee_len = ext4_ext_get_actual_len(ex2); + zero_ex.ee_len = cpu_to_le16( + ext4_ext_get_actual_len(ex2)); ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(ex2)); } else { err = ext4_ext_zeroout(inode, ex); zero_ex.ee_block = ex->ee_block; - zero_ex.ee_len = ext4_ext_get_actual_len(ex); + zero_ex.ee_len = cpu_to_le16( + ext4_ext_get_actual_len(ex)); ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(ex)); } } else { err = ext4_ext_zeroout(inode, &orig_ex); zero_ex.ee_block = orig_ex.ee_block; - zero_ex.ee_len = ext4_ext_get_actual_len(&orig_ex); + zero_ex.ee_len = cpu_to_le16( + ext4_ext_get_actual_len(&orig_ex)); ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(&orig_ex)); } @@ -3272,7 +3275,7 @@ static int ext4_ext_convert_to_initialized(handle_t *handle, if (err) goto out; zero_ex.ee_block = ex->ee_block; - zero_ex.ee_len = ext4_ext_get_actual_len(ex); + zero_ex.ee_len = cpu_to_le16(ext4_ext_get_actual_len(ex)); ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(ex)); err = ext4_ext_get_access(handle, inode, path + depth); -- 1.7.12.rc2.18.g61b472e ^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out 2013-04-03 10:22 ` Zheng Liu @ 2013-04-03 12:20 ` Theodore Ts'o 2013-04-03 12:29 ` Dmitry Monakhov 2013-04-03 14:34 ` Eric Whitney 0 siblings, 2 replies; 42+ messages in thread From: Theodore Ts'o @ 2013-04-03 12:20 UTC (permalink / raw) To: Dmitry Monakhov, Christian Kujau, CAI Qian, LKML, linux-s390, Steve Best, linux-ext4 On Wed, Apr 03, 2013 at 06:22:04PM +0800, Zheng Liu wrote: > Subject: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out > > From: Zheng Liu <wenqing.lz@taobao.com> > > When an extent was zeroed out, we forgot to do convert from cpu to le16. > It could make us hit a BUG_ON when we try to write dirty pages out. So > fix it. > > Signed-off-by: Zheng Liu <wenqing.lz@taobao.com> Thanks for finding this! I think we should push this to Linus right away, and not wait for the next merge window. The bug has been here for a long time, but it was unmasked by the fact that we unbroke extent zeroing in 3.9-rcX. I have two big questions. (1) Shouldn't Eric Whitney have picked this up with his ARM pandaboard testing, since IIRC it's big-endian as well? If not, is there something we can do to improve our testing wrt to big-endian systems? And (2) does it make sense to have an inline function ext4_ext_set_len(len)? It might save some lines of code, but more importantly, it might make it less likely that we will overlook this sort of bug in the future. - Ted ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out 2013-04-03 12:20 ` [PATCH] ext4: fix a big-endian bug when an extent is zeroed out Theodore Ts'o @ 2013-04-03 12:29 ` Dmitry Monakhov 2013-04-03 14:34 ` Eric Whitney 1 sibling, 0 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-03 12:29 UTC (permalink / raw) To: Theodore Ts'o, Christian Kujau, CAI Qian, LKML, linux-s390, Steve Best, linux-ext4 On Wed, 3 Apr 2013 08:20:58 -0400, Theodore Ts'o <tytso@mit.edu> wrote: > On Wed, Apr 03, 2013 at 06:22:04PM +0800, Zheng Liu wrote: > > Subject: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out > > > > From: Zheng Liu <wenqing.lz@taobao.com> > > > > When an extent was zeroed out, we forgot to do convert from cpu to le16. > > It could make us hit a BUG_ON when we try to write dirty pages out. So > > fix it. > > > > Signed-off-by: Zheng Liu <wenqing.lz@taobao.com> > > Thanks for finding this! I think we should push this to Linus right > away, and not wait for the next merge window. The bug has been here > for a long time, but it was unmasked by the fact that we unbroke > extent zeroing in 3.9-rcX. IMHO you have to pick this one http://patchwork.ozlabs.org/patch/233397 because it also fix ext_to_indirect_migration and inode's csum > > I have two big questions. (1) Shouldn't Eric Whitney have picked this > up with his ARM pandaboard testing, since IIRC it's big-endian as > well? If not, is there something we can do to improve our testing wrt > to big-endian systems? > > And (2) does it make sense to have an inline function > ext4_ext_set_len(len)? It might save some lines of code, but more > importantly, it might make it less likely that we will overlook this > sort of bug in the future. Let's live it for now, later I'll cleanup/optimize this 'zero_ex' at least from from ext4_split_extent_at because at the end we are shure that 'ex' is fully mapped and initialized > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out 2013-04-03 12:20 ` [PATCH] ext4: fix a big-endian bug when an extent is zeroed out Theodore Ts'o 2013-04-03 12:29 ` Dmitry Monakhov @ 2013-04-03 14:34 ` Eric Whitney 2013-04-03 14:41 ` Theodore Ts'o 1 sibling, 1 reply; 42+ messages in thread From: Eric Whitney @ 2013-04-03 14:34 UTC (permalink / raw) To: Theodore Ts'o, Dmitry Monakhov, Christian Kujau, CAI Qian, LKML, linux-s390, Steve Best, linux-ext4 * Theodore Ts'o <tytso@mit.edu>: > On Wed, Apr 03, 2013 at 06:22:04PM +0800, Zheng Liu wrote: > > Subject: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out > > > > From: Zheng Liu <wenqing.lz@taobao.com> > > > > When an extent was zeroed out, we forgot to do convert from cpu to le16. > > It could make us hit a BUG_ON when we try to write dirty pages out. So > > fix it. > > > > Signed-off-by: Zheng Liu <wenqing.lz@taobao.com> > > Thanks for finding this! I think we should push this to Linus right > away, and not wait for the next merge window. The bug has been here > for a long time, but it was unmasked by the fact that we unbroke > extent zeroing in 3.9-rcX. > > I have two big questions. (1) Shouldn't Eric Whitney have picked this > up with his ARM pandaboard testing, since IIRC it's big-endian as > well? If not, is there something we can do to improve our testing wrt > to big-endian systems? The TI OMAP4 processor on my Pandaboard test system is little endian. Eric > > And (2) does it make sense to have an inline function > ext4_ext_set_len(len)? It might save some lines of code, but more > importantly, it might make it less likely that we will overlook this > sort of bug in the future. > > - Ted > -- > 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] 42+ messages in thread
* Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out 2013-04-03 14:34 ` Eric Whitney @ 2013-04-03 14:41 ` Theodore Ts'o 2013-04-03 15:23 ` Florian Fainelli 2013-04-09 3:05 ` CAI Qian 0 siblings, 2 replies; 42+ messages in thread From: Theodore Ts'o @ 2013-04-03 14:41 UTC (permalink / raw) To: Eric Whitney Cc: Dmitry Monakhov, Christian Kujau, CAI Qian, LKML, linux-s390, Steve Best, linux-ext4 On Wed, Apr 03, 2013 at 10:34:06AM -0400, Eric Whitney wrote: > > The TI OMAP4 processor on my Pandaboard test system is little endian. Ah... so basically, we need to find a test platform which allows us to boot arbitrary kernels and allows us to have root access (which means it's unlikely we'll be able to do this via remote access) and which doesn't have exotic power requirements (which as far as I know rules out pSeries and zSeries systems....) It would also be nice if we could run tests in finite time, which probably rules out the Hercules emulator (it runs at one-tenth zSeries processor speeds, which doesn't win speed competitions by default, and I suspect their storage speeds are even worse). Anyone else have any suggestions? Or anyone willing to help us run ext4 regression tests on the ext4 dev tree, so we can find these problems before we merge into mainline? Thanks, - Ted ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out 2013-04-03 14:41 ` Theodore Ts'o @ 2013-04-03 15:23 ` Florian Fainelli 2013-04-09 3:05 ` CAI Qian 1 sibling, 0 replies; 42+ messages in thread From: Florian Fainelli @ 2013-04-03 15:23 UTC (permalink / raw) To: Theodore Ts'o, Eric Whitney, Dmitry Monakhov, Christian Kujau, CAI Qian, LKML, linux-s390, Steve Best, linux-ext4 Hello, Le 04/03/13 16:41, Theodore Ts'o a écrit : > On Wed, Apr 03, 2013 at 10:34:06AM -0400, Eric Whitney wrote: >> >> The TI OMAP4 processor on my Pandaboard test system is little endian. > > Ah... so basically, we need to find a test platform which allows us to > boot arbitrary kernels and allows us to have root access (which means > it's unlikely we'll be able to do this via remote access) and which > doesn't have exotic power requirements (which as far as I know rules > out pSeries and zSeries systems....) > > It would also be nice if we could run tests in finite time, which > probably rules out the Hercules emulator (it runs at one-tenth zSeries > processor speeds, which doesn't win speed competitions by default, and > I suspect their storage speeds are even worse). > > Anyone else have any suggestions? Or anyone willing to help us run > ext4 regression tests on the ext4 dev tree, so we can find these > problems before we merge into mainline? Qemu emulates various mainline PowerPC, MIPS and SPARC big-endian systems pretty efficiently and it should not be too hard neither to script nor to get a recent kernel up and running on these platforms. My 2 cents. -- Florian ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out @ 2013-04-03 15:23 ` Florian Fainelli 0 siblings, 0 replies; 42+ messages in thread From: Florian Fainelli @ 2013-04-03 15:23 UTC (permalink / raw) To: Theodore Ts'o, Eric Whitney, Dmitry Monakhov, Christian Kujau, CAI Qian, LKML, linux-s390, Steve Best, linux-ext4 Hello, Le 04/03/13 16:41, Theodore Ts'o a écrit : > On Wed, Apr 03, 2013 at 10:34:06AM -0400, Eric Whitney wrote: >> >> The TI OMAP4 processor on my Pandaboard test system is little endian. > > Ah... so basically, we need to find a test platform which allows us to > boot arbitrary kernels and allows us to have root access (which means > it's unlikely we'll be able to do this via remote access) and which > doesn't have exotic power requirements (which as far as I know rules > out pSeries and zSeries systems....) > > It would also be nice if we could run tests in finite time, which > probably rules out the Hercules emulator (it runs at one-tenth zSeries > processor speeds, which doesn't win speed competitions by default, and > I suspect their storage speeds are even worse). > > Anyone else have any suggestions? Or anyone willing to help us run > ext4 regression tests on the ext4 dev tree, so we can find these > problems before we merge into mainline? Qemu emulates various mainline PowerPC, MIPS and SPARC big-endian systems pretty efficiently and it should not be too hard neither to script nor to get a recent kernel up and running on these platforms. My 2 cents. -- Florian -- 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] 42+ messages in thread
* Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out 2013-04-03 14:41 ` Theodore Ts'o 2013-04-03 15:23 ` Florian Fainelli @ 2013-04-09 3:05 ` CAI Qian 2013-04-20 15:19 ` Theodore Ts'o 1 sibling, 1 reply; 42+ messages in thread From: CAI Qian @ 2013-04-09 3:05 UTC (permalink / raw) To: Theodore Ts'o Cc: Eric Whitney, Dmitry Monakhov, Christian Kujau, LKML, linux-s390, Steve Best, linux-ext4 Hello Ted, ----- Original Message ----- > From: "Theodore Ts'o" <tytso@mit.edu> > To: "Eric Whitney" <enwlinux@gmail.com> > Cc: "Dmitry Monakhov" <dmonakhov@openvz.org>, "Christian Kujau" <lists@nerdbynature.de>, "CAI Qian" > <caiqian@redhat.com>, "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" <linux-s390@vger.kernel.org>, "Steve Best" > <sbest@redhat.com>, linux-ext4@vger.kernel.org > Sent: Wednesday, April 3, 2013 10:41:14 PM > Subject: Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out > > On Wed, Apr 03, 2013 at 10:34:06AM -0400, Eric Whitney wrote: > > > > The TI OMAP4 processor on my Pandaboard test system is little endian. > > Ah... so basically, we need to find a test platform which allows us to > boot arbitrary kernels and allows us to have root access (which means > it's unlikely we'll be able to do this via remote access) and which > doesn't have exotic power requirements (which as far as I know rules > out pSeries and zSeries systems....) > > It would also be nice if we could run tests in finite time, which > probably rules out the Hercules emulator (it runs at one-tenth zSeries > processor speeds, which doesn't win speed competitions by default, and > I suspect their storage speeds are even worse). > > Anyone else have any suggestions? Or anyone willing to help us run > ext4 regression tests on the ext4 dev tree, so we can find these > problems before we merge into mainline? I can help run xfstests for ext4 dev tree on x64, Power7, Z10 and KVM platforms with back-storage like SAN/multipath, iSCSI and FCoE. I plan to run this weekly and setup a wiki page to update the testing status by every Friday. CAI Qian > > Thanks, > > - Ted > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out 2013-04-09 3:05 ` CAI Qian @ 2013-04-20 15:19 ` Theodore Ts'o 2013-04-22 3:40 ` CAI Qian 2013-04-22 10:04 ` Christian Borntraeger 0 siblings, 2 replies; 42+ messages in thread From: Theodore Ts'o @ 2013-04-20 15:19 UTC (permalink / raw) To: CAI Qian Cc: Eric Whitney, Dmitry Monakhov, Christian Kujau, LKML, linux-s390, Steve Best, linux-ext4 On Mon, Apr 08, 2013 at 11:05:11PM -0400, CAI Qian wrote: > I can help run xfstests for ext4 dev tree on x64, Power7, Z10 and > KVM platforms with back-storage like SAN/multipath, iSCSI and FCoE. > I plan to run this weekly and setup a wiki page to update the testing > status by every Friday. Hi CAI, Sorry for not getting back to you sooner; I was at Collaboration Summit and LSF/MM last week. It would be great if you could help run xfstests on the ext4 dev tree on various platforms. We don't have any coverage on Power7 or s390/Z10 at the moment, so that would be especially welcome. Coverage on alternate storage backends can be interesting in finding timing problems so they would be valuable as well. If you have any Itanium platforms, that would be great too, since we don't have that today. The various ext4 configurations which I test can be found in the kvm-autorun/conf directory in my xfstests-bld git repository: git://git.kernel.org/pub/scm/fs/ext2/xfstests-bld.git (This repository is a convenient setup to do build xfstests in a hermetic environment, and convenience scripts to run xfstests under kvm, and scripts on the host OS kick off the kvm test run and parse the test output afterwards.) Thanks for offering to test the dev branch! - Ted ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out 2013-04-20 15:19 ` Theodore Ts'o @ 2013-04-22 3:40 ` CAI Qian 2013-04-22 10:04 ` Christian Borntraeger 1 sibling, 0 replies; 42+ messages in thread From: CAI Qian @ 2013-04-22 3:40 UTC (permalink / raw) To: Theodore Ts'o Cc: Eric Whitney, Dmitry Monakhov, Christian Kujau, LKML, linux-ext4 Hi Ted, ----- Original Message ----- > From: "Theodore Ts'o" <tytso@mit.edu> > To: "CAI Qian" <caiqian@redhat.com> > Cc: "Eric Whitney" <enwlinux@gmail.com>, "Dmitry Monakhov" <dmonakhov@openvz.org>, "Christian Kujau" > nerdbynature.de>, "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" <linux-s390@vger.kernel.org>, "Steve > Best" <sbest@redhat.com>, linux-ext4@vger.kernel.org > Sent: Saturday, April 20, 2013 11:19:45 PM > Subject: Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out > > On Mon, Apr 08, 2013 at 11:05:11PM -0400, CAI Qian wrote: > > I can help run xfstests for ext4 dev tree on x64, Power7, Z10 and > > KVM platforms with back-storage like SAN/multipath, iSCSI and FCoE. > > I plan to run this weekly and setup a wiki page to update the testing > > status by every Friday. > > Hi CAI, > > Sorry for not getting back to you sooner; I was at Collaboration > Summit and LSF/MM last week. > > It would be great if you could help run xfstests on the ext4 dev tree > on various platforms. We don't have any coverage on Power7 or > s390/Z10 at the moment, so that would be especially welcome. Coverage > on alternate storage backends can be interesting in finding timing > problems so they would be valuable as well. > > If you have any Itanium platforms, that would be great too, since we > don't have that today. Unfortunately, to get those ia64 up and running with the upstream kernel required some significant efforts. I'd leave that for now until it is something very important. > > The various ext4 configurations which I test can be found in the > kvm-autorun/conf directory in my xfstests-bld git repository: > > git://git.kernel.org/pub/scm/fs/ext2/xfstests-bld.git > > (This repository is a convenient setup to do build xfstests in a > hermetic environment, and convenience scripts to run xfstests under > kvm, and scripts on the host OS kick off the kvm test run and parse > the test output afterwards.) > > Thanks for offering to test the dev branch! OK, will check with that. BTW, git.kernel.org is kind of broken for me very often those days, as almost all my tests got this, + git clone http://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git -b dev Cloning into 'ext4'... fatal: The remote end hung up unexpectedly fatal: recursion detected in die handler Therefore, it is going to take a while to re-try later as the test systems here always do testing from a clean environment, i.e., re-install OS, and then re-clone the tree etc. :\ CAI Qian > > - Ted > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out 2013-04-20 15:19 ` Theodore Ts'o 2013-04-22 3:40 ` CAI Qian @ 2013-04-22 10:04 ` Christian Borntraeger 1 sibling, 0 replies; 42+ messages in thread From: Christian Borntraeger @ 2013-04-22 10:04 UTC (permalink / raw) To: Theodore Ts'o Cc: CAI Qian, Eric Whitney, Dmitry Monakhov, Christian Kujau, LKML, linux-s390, Steve Best, linux-ext4 On 20/04/13 17:19, Theodore Ts'o wrote: > On Mon, Apr 08, 2013 at 11:05:11PM -0400, CAI Qian wrote: >> I can help run xfstests for ext4 dev tree on x64, Power7, Z10 and >> KVM platforms with back-storage like SAN/multipath, iSCSI and FCoE. >> I plan to run this weekly and setup a wiki page to update the testing >> status by every Friday. > > Hi CAI, > > Sorry for not getting back to you sooner; I was at Collaboration > Summit and LSF/MM last week. > > It would be great if you could help run xfstests on the ext4 dev tree > on various platforms. We don't have any coverage on Power7 or > s390/Z10 at the moment, so that would be especially welcome. Coverage > on alternate storage backends can be interesting in finding timing > problems so they would be valuable as well. It is probably easier to get access to a Power system (gcc compile farm?). Having said that, there is a service available to get access to a System z for open source development: http://www-03.ibm.com/systems/z/os/linux/support/community.html When we did the valgrind port we used that a lot to gave access to non-IBMers. Dont know if it is ok to install a private kernel, though. Will double check. Christian ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) 2013-04-03 9:53 ` Dmitry Monakhov 2013-04-03 10:22 ` Zheng Liu @ 2013-04-03 11:02 ` Dmitry Monakhov [not found] ` <alpine.DEB.2.10.1304030935230.13746@trent.utfs.org> 1 sibling, 1 reply; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-03 11:02 UTC (permalink / raw) To: Christian Kujau Cc: CAI Qian, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4, Zheng Liu On Wed, 03 Apr 2013 13:53:49 +0400, Dmitry Monakhov <dmonakhov@openvz.org> wrote: Non-text part: multipart/mixed > On Wed, 03 Apr 2013 12:52:06 +0400, Dmitry Monakhov <dmonakhov@openvz.org> wrote: > Non-text part: multipart/mixed > > On Tue, 2 Apr 2013 16:22:41 -0700 (PDT), Christian Kujau <lists@nerdbynature.de> wrote: > > > On Wed, 3 Apr 2013 at 02:05, Dmitry Monakhov wrote: > > > > Please drop that patch and collect logs with a kernel which > > > > has only 0001-enable-ES_AGGRESSIVE_TEST-V2.patch patch applied Good news big endian cpu owners Please try following patches(second is most important): http://patchwork.ozlabs.org/patch/233396/ http://patchwork.ozlabs.org/patch/233397/ I hope this should fix all known issues > > Ok I have found at least one issue. > Yeah.. My college advise me to use sparse in order to spot all > cpu_to_ondisk format conversion > make C=2 CF="-D__CHECK_ENDIAN__" fs/ext4/ > And it spotted a huge amount of issues. Which tell us that we are deeply > in shit. > <stdin>:1220:2: warning: #warning syscall kcmp not implemented > <stdin>:1223:2: warning: #warning syscall finit_module not implemented > fs/ext4/ialloc.c:902:37: warning: symbol 'sbi' shadows an earlier one > fs/ext4/ialloc.c:650:29: originally declared here > fs/ext4/inode.c:58:17: warning: incorrect type in assignment (different base types) > fs/ext4/inode.c:58:17: expected unsigned short [unsigned] [usertype] csum_lo > fs/ext4/inode.c:58:17: got restricted __le16 [usertype] l_i_checksum_lo > fs/ext4/inode.c:62:25: warning: incorrect type in assignment (different base types) > fs/ext4/inode.c:62:25: expected unsigned short [unsigned] [usertype] csum_hi > fs/ext4/inode.c:62:25: got restricted __le16 [usertype] i_checksum_hi > fs/ext4/inode.c:69:28: warning: incorrect type in assignment (different base types) > fs/ext4/inode.c:69:28: expected restricted __le16 [usertype] l_i_checksum_lo > fs/ext4/inode.c:69:28: got unsigned short [unsigned] [usertype] csum_lo > fs/ext4/inode.c:72:36: warning: incorrect type in assignment (different base types) > fs/ext4/inode.c:72:36: expected restricted __le16 [usertype] i_checksum_hi > fs/ext4/inode.c:72:36: got unsigned short [unsigned] [usertype] csum_hi > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > fs/ext4/ioctl.c:358:36: warning: symbol 'sb' shadows an earlier one > fs/ext4/ioctl.c:26:28: originally declared here > fs/ext4/namei.c:2008:36: warning: potentially expensive pointer subtraction > fs/ext4/namei.c:423:18: warning: incorrect type in assignment (different base types) > fs/ext4/namei.c:423:18: expected unsigned int [unsigned] [usertype] old_csum > fs/ext4/namei.c:423:18: got restricted __le32 [usertype] dt_checksum > fs/ext4/namei.c:427:24: warning: incorrect type in assignment (different base types) > fs/ext4/namei.c:427:24: expected restricted __le32 [usertype] dt_checksum > fs/ext4/namei.c:427:24: got unsigned int [unsigned] [usertype] old_csum > include/trace/events/ext4.h:1926:1: warning: cast from restricted __le32 > include/trace/events/ext4.h:1926:1: warning: incorrect type in assignment (different base types) > include/trace/events/ext4.h:1926:1: expected unsigned int [unsigned] [usertype] ee_lblk > include/trace/events/ext4.h:1926:1: got restricted __le32 [usertype] <noident> > include/trace/events/ext4.h:1926:1: warning: cast from restricted __le32 > include/trace/events/ext4.h:1926:1: warning: incorrect type in assignment (different base types) > include/trace/events/ext4.h:1926:1: expected unsigned int [unsigned] [usertype] ee_lblk > include/trace/events/ext4.h:1926:1: got restricted __le32 [usertype] <noident> > fs/ext4/super.c:1957:26: warning: incorrect type in assignment (different base types) > fs/ext4/super.c:1957:26: expected unsigned short [unsigned] [usertype] old_csum > fs/ext4/super.c:1957:26: got restricted __le16 [usertype] bg_checksum > fs/ext4/super.c:1963:34: warning: incorrect type in assignment (different base types) > fs/ext4/super.c:1963:34: expected restricted __le16 [usertype] bg_checksum > fs/ext4/super.c:1963:34: got unsigned short [unsigned] [usertype] old_csum > include/uapi/linux/swab.h:60:16: error: undefined identifier '__builtin_bswap32' > include/uapi/linux/swab.h:60:33: error: not a function <noident> > fs/ext4/extents.c:3002:48: warning: incorrect type in assignment (different base types) > fs/ext4/extents.c:3002:48: expected restricted __le16 [assigned] [usertype] ee_len > fs/ext4/extents.c:3002:48: got restricted __be16 [usertype] <noident> > fs/ext4/extents.c:3008:48: warning: incorrect type in assignment (different base types) > fs/ext4/extents.c:3008:48: expected restricted __le16 [addressable] [assigned] [usertype] ee_len > fs/ext4/extents.c:3008:48: got restricted __be16 [usertype] <noident> > fs/ext4/extents.c:3015:40: warning: incorrect type in assignment (different base types) > fs/ext4/extents.c:3015:40: expected restricted __le16 [addressable] [assigned] [usertype] ee_len > fs/ext4/extents.c:3015:40: got restricted __be16 [usertype] <noident> > fs/ext4/extents.c:603:28: warning: potentially expensive pointer subtraction > fs/ext4/extents.c:671:28: warning: potentially expensive pointer subtraction > fs/ext4/extents.c:849:43: warning: potentially expensive pointer subtraction > fs/ext4/extents.c:984:47: warning: potentially expensive pointer subtraction > fs/ext4/extents.c:1063:50: warning: potentially expensive pointer subtraction > fs/ext4/extents.c:1656:52: warning: potentially expensive pointer subtraction > fs/ext4/extents.c:1706:32: warning: potentially expensive pointer subtraction > fs/ext4/extents.c:1929:43: warning: potentially expensive pointer subtraction > fs/ext4/extents.c:2206:55: warning: potentially expensive pointer subtraction > fs/ext4/extents.c:2528:72: warning: potentially expensive pointer subtraction > fs/ext4/extents.c:2787:36: warning: incorrect type in argument 5 (different base types) > fs/ext4/extents.c:2787:36: expected unsigned short [unsigned] eh_entries > fs/ext4/extents.c:2787:36: got restricted __le16 [usertype] eh_entries > fs/ext4/extents.c:3275:32: warning: incorrect type in assignment (different base types) > fs/ext4/extents.c:3275:32: expected restricted __le16 [assigned] [usertype] ee_len > fs/ext4/extents.c:3275:32: got restricted __be16 [usertype] <noident> > fs/ext4/extents.c:4642:34: warning: cast from restricted __le16 > fs/ext4/extents.c:4642:34: warning: incorrect type in argument 1 (different base types) > fs/ext4/extents.c:4642:34: expected unsigned short [unsigned] [usertype] val > fs/ext4/extents.c:4642:34: got restricted __le16 [usertype] eh_entries > fs/ext4/extents.c:4642:34: warning: cast from restricted __le16 > fs/ext4/extents.c:4642:34: warning: cast from restricted __le16 > fs/ext4/extents.c:4642:34: warning: restricted __be16 degrades to integer > fs/ext4/mballoc.c:863:21: warning: symbol 'group' shadows an earlier one > fs/ext4/mballoc.c:795:35: originally declared here > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > fs/ext4/mballoc.c:4855:9: warning: context imbalance in 'ext4_trim_extent' - unexpected unlock > fs/ext4/move_extent.c:859:29: warning: symbol 'err' shadows an earlier one > fs/ext4/move_extent.c:835:16: originally declared here > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > fs/ext4/mmp.c:18:16: warning: incorrect type in return expression (different base types) > fs/ext4/mmp.c:18:16: expected unsigned int > fs/ext4/mmp.c:18:16: got restricted __le32 [usertype] <noident> > fs/ext4/mmp.c:27:19: warning: restricted __le32 degrades to integer > fs/ext4/mmp.c:36:27: warning: incorrect type in assignment (different base types) > fs/ext4/mmp.c:36:27: expected restricted __le32 [usertype] mmp_checksum > fs/ext4/mmp.c:36:27: got unsigned int > fs/ext4/indirect.c:579:41: warning: potentially expensive pointer subtraction > fs/ext4/indirect.c:592:52: warning: potentially expensive pointer subtraction > fs/ext4/indirect.c:1257:68: warning: potentially expensive pointer subtraction > fs/ext4/indirect.c:1268:67: warning: potentially expensive pointer subtraction > fs/ext4/indirect.c:1275:48: warning: potentially expensive pointer subtraction > fs/ext4/indirect.c:1327:52: warning: incorrect type in argument 2 (different base types) > fs/ext4/indirect.c:1327:52: expected unsigned long [unsigned] [usertype] block > fs/ext4/indirect.c:1327:52: got restricted __le32 [assigned] [usertype] blk > fs/ext4/indirect.c:1329:33: warning: incorrect type in argument 4 (different base types) > fs/ext4/indirect.c:1329:33: expected unsigned long long [unsigned] [usertype] <noident> > fs/ext4/indirect.c:1329:33: got restricted __le32 [assigned] [usertype] blk > fs/ext4/xattr.c:127:13: warning: incorrect type in assignment (different base types) > fs/ext4/xattr.c:127:13: expected unsigned int [unsigned] [usertype] old > fs/ext4/xattr.c:127:13: got restricted __le32 [usertype] h_checksum > fs/ext4/xattr.c:129:18: warning: incorrect type in assignment (different base types) > fs/ext4/xattr.c:129:18: expected unsigned long [unsigned] [usertype] block_nr > fs/ext4/xattr.c:129:18: got restricted __le64 [usertype] <noident> > fs/ext4/xattr.c:135:25: warning: incorrect type in assignment (different base types) > fs/ext4/xattr.c:135:25: expected restricted __le32 [usertype] h_checksum > fs/ext4/xattr.c:135:25: got unsigned int [unsigned] [usertype] old > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > include/linux/mm.h:759:16: warning: potentially expensive pointer subtraction > So please give me couple of hours and I'll send you a complete patch. > > > > Please give a try to this patch > > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c > > index 1530cf4..e8460f6 100644 > > --- a/fs/ext4/extents.c > > +++ b/fs/ext4/extents.c > > @@ -3272,7 +3272,7 @@ static int ext4_ext_convert_to_initialized(handle_t *handle, > > if (err) > > goto out; > > zero_ex.ee_block = ex->ee_block; > > - zero_ex.ee_len = ext4_ext_get_actual_len(ex); > > + zero_ex.ee_len = cpu_to_le16(ext4_ext_get_actual_len(ext)); > > ext4_ext_store_pblock(&zero_ex, ext4_ext_pblock(ex)); > > > > err = ext4_ext_get_access(handle, inode, path + depth); > > > > > > > > I've applied (only) 0001-enable-ES_AGGRESSIVE_TEST-V2.patch to 3.9-rc4: > > > > > > patching file fs/ext4/extents_status.h > > > patching file fs/ext4/inode.c > > > Hunk #1 succeeded at 1588 (offset 42 lines). > > > Hunk #2 succeeded at 1609 (offset 42 lines). > > > > > > And tried to download some images via bittorrent. As expected, lots of > > > "ES cache assertation failed" were being logged: > > > > > > http://nerdbynature.de/bits/3.9.0-rc4/ext4/ > > > => messages_0001-enable-ES_AGGRESSIVE_TEST-V2.txt.xz > > > > > > I've tried to download 3 files, all via bittorrent (so, fallocate & heavy > > > mmap) > > > > > > 1) 8GB Fedora iso, there are also WARNINGs bring triggered, see below. > > > I decided to cancel the download after some gigabyes. > > > > > > 2) A 50 MB Debian iso, this produced just one "ES cache assertation" > > > message. Download went OK, checksum was correct too. > > > > > > 3) A 221 MB Fedora iso, produced a couple of "ES cache assertation" > > > messages, but no WARNINGs. Download went OK, checksum was correct too. > > > > > > It's all in that messages_0001-enable-ES_AGGRESSIVE_TEST-V2.txt.xz file > > > above. I just e2fsck'ed the ext4 filesystem again (and did so last night), > > > but no errors were found. > > > > > > HTH, > > > Christian. > > > > > > One of the WARNINGs during that 8GB download: > > > > > > ino:39190654 lbkl:0, b_state=0x0004b988, b_size=4131 > > > ------------[ cut here ]------------ > > > WARNING: at /opt/linux-git/fs/ext4/inode.c:1600 > > > Modules linked in: md5 ecb nfs i2c_powermac therm_adt746x ecryptfs firewire_sbp2 arc4 b43 usb_storage mac80211 cfg80211 > > > NIP: c013745c LR: c013745c CTR: c000df9c > > > REGS: edc479a0 TRAP: 0700 Tainted: G W (3.9.0-rc4-dirty) > > > MSR: 00029032 <EE,ME,IR,DR,RI> CR: 44028644 XER: 20000000 > > > TASK = edca9740[4379] 'flush-254:1' THREAD: edc46000 > > > GPR00: c013745c edc47a50 edca9740 00000034 edca9db0 00000006 00000000 00008000 > > > GPR08: 00003fb0 00218f23 00000000 c000006e 00000dc9 00000000 00000009 ee18cca0 > > > GPR16: edc47c78 0000000e 0004b9bf 0004b988 00000000 edc47a84 00001000 e6357540 > > > GPR24: edc47b78 e6357540 00000000 0004b97f 00000000 0051d188 00000000 0004b988 > > > NIP [c013745c] mpage_da_submit_io+0x3dc/0x3f0 > > > LR [c013745c] mpage_da_submit_io+0x3dc/0x3f0 > > > Call Trace: > > > [edc47a50] [c013745c] mpage_da_submit_io+0x3dc/0x3f0 (unreliable) > > > [edc47b30] [c013c9f0] mpage_da_map_and_submit+0x16c/0x5f0 > > > [edc47bc0] [c013d2e4] write_cache_pages_da+0x470/0x480 > > > [edc47c70] [c013d554] ext4_da_writepages+0x260/0x49c > > > [edc47d20] [c00eeea0] __writeback_single_inode+0x34/0x120 > > > [edc47d40] [c00ef508] writeback_sb_inodes+0x1fc/0x34c > > > [edc47db0] [c00ef6e4] __writeback_inodes_wb+0x8c/0xd0 > > > [edc47de0] [c00efa90] wb_writeback+0x1b4/0x1bc > > > [edc47e20] [c00f06d0] wb_do_writeback+0x1ec/0x1f4 > > > [edc47e80] [c00f0748] bdi_writeback_thread+0x70/0x140 > > > [edc47eb0] [c0051c18] kthread+0xa8/0xac > > > [edc47f40] [c00106cc] ret_from_kernel_thread+0x64/0x6c > > > --- Exception: 0 at (null) > > > LR = (null) > > > Instruction dump: > > > > > > -- > > > BOFH excuse #61: > > > > > > not approved by the FCC ^ permalink raw reply [flat|nested] 42+ messages in thread
[parent not found: <alpine.DEB.2.10.1304030935230.13746@trent.utfs.org>]
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) [not found] ` <alpine.DEB.2.10.1304030935230.13746@trent.utfs.org> @ 2013-04-03 16:50 ` Dmitry Monakhov 2013-04-03 16:52 ` Zheng Liu 1 sibling, 0 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-03 16:50 UTC (permalink / raw) To: Christian Kujau Cc: CAI Qian, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4, Zheng Liu On Wed, 3 Apr 2013 09:46:56 -0700 (PDT), Christian Kujau <lists@nerdbynature.de> wrote: > On Wed, 3 Apr 2013 at 15:02, Dmitry Monakhov wrote: > > Good news big endian cpu owners > > Please try following patches(second is most important): > > http://patchwork.ozlabs.org/patch/233396/ > > http://patchwork.ozlabs.org/patch/233397/ > > I hope this should fix all known issues > > Zheng Liu also sent a patch: > > [PATCH] ext4: fix a big-endian bug when an extent is zeroed out > > When I try to apply all three of those to 3.9-4c4, the 2nd one from Dmitry > fails: Yes. becase my patch was against ext4.git/dev so just ignore it. Teodore have sent a patch http://patchwork.ozlabs.org/patch/233555/ This is most probable candidate for final fix. > > $ cat ~/dev/002-ext4_fix-cpu_vs_disk-conversions.diff | patch --dry-run -p1 > patching file fs/ext4/extents.c > Hunk #2 FAILED at 2999. > Hunk #3 FAILED at 3272. > Hunk #4 FAILED at 4639. > 3 out of 4 hunks FAILED -- saving rejects to file fs/ext4/extents.c.rej > patching file fs/ext4/indirect.c > Hunk #1 succeeded at 1539 (offset 215 lines). > patching file fs/ext4/inode.c > patching file fs/ext4/mmp.c > patching file fs/ext4/namei.c > patching file fs/ext4/super.c > Hunk #1 succeeded at 1951 (offset -3 lines). > patching file fs/ext4/xattr.c > patching file include/trace/events/ext4.h > Hunk #1 succeeded at 1956 (offset 8 lines). > Hunk #2 succeeded at 2060 (offset 8 lines). > Hunk #3 succeeded at 2079 (offset 8 lines). > > With only Dimitry's patchesm this happens, to -rc4: > > $ cat ~/dev/001-ext4_fix-usless-declarations.diff | patch -p1 > patching file fs/ext4/ialloc.c > patching file fs/ext4/ioctl.c > Hunk #1 succeeded at 359 (offset 4 lines). > patching file fs/ext4/mballoc.c > patching file fs/ext4/move_extent.c > > $ cat ~/dev/002-ext4_fix-cpu_vs_disk-conversions.diff | patch --dry-run -p1 > patching file fs/ext4/extents.c > Hunk #4 FAILED at 4639. > 1 out of 4 hunks FAILED -- saving rejects to file fs/ext4/extents.c.rej > patching file fs/ext4/indirect.c > Hunk #1 succeeded at 1539 (offset 215 lines). > patching file fs/ext4/inode.c > patching file fs/ext4/mmp.c > patching file fs/ext4/namei.c > patching file fs/ext4/super.c > Hunk #1 succeeded at 1951 (offset -3 lines). > patching file fs/ext4/xattr.c > patching file include/trace/events/ext4.h > Hunk #1 succeeded at 1956 (offset 8 lines). > Hunk #2 succeeded at 2060 (offset 8 lines). > Hunk #3 succeeded at 2079 (offset 8 lines). > > > Christian. > -- > BOFH excuse #451: > > astropneumatic oscillations in the water-cooling ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) [not found] ` <alpine.DEB.2.10.1304030935230.13746@trent.utfs.org> 2013-04-03 16:50 ` Dmitry Monakhov @ 2013-04-03 16:52 ` Zheng Liu 1 sibling, 0 replies; 42+ messages in thread From: Zheng Liu @ 2013-04-03 16:52 UTC (permalink / raw) To: Christian Kujau Cc: Dmitry Monakhov, CAI Qian, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 On 04/04/2013 12:46 AM, Christian Kujau wrote: > On Wed, 3 Apr 2013 at 15:02, Dmitry Monakhov wrote: >> Good news big endian cpu owners >> Please try following patches(second is most important): >> http://patchwork.ozlabs.org/patch/233396/ >> http://patchwork.ozlabs.org/patch/233397/ >> I hope this should fix all known issues > > Zheng Liu also sent a patch: > > [PATCH] ext4: fix a big-endian bug when an extent is zeroed out > > When I try to apply all three of those to 3.9-4c4, the 2nd one from Dmitry > fails: > > $ cat ~/dev/002-ext4_fix-cpu_vs_disk-conversions.diff | patch --dry-run -p1 > patching file fs/ext4/extents.c > Hunk #2 FAILED at 2999. > Hunk #3 FAILED at 3272. > Hunk #4 FAILED at 4639. > 3 out of 4 hunks FAILED -- saving rejects to file fs/ext4/extents.c.rej > patching file fs/ext4/indirect.c > Hunk #1 succeeded at 1539 (offset 215 lines). > patching file fs/ext4/inode.c > patching file fs/ext4/mmp.c > patching file fs/ext4/namei.c > patching file fs/ext4/super.c > Hunk #1 succeeded at 1951 (offset -3 lines). > patching file fs/ext4/xattr.c > patching file include/trace/events/ext4.h > Hunk #1 succeeded at 1956 (offset 8 lines). > Hunk #2 succeeded at 2060 (offset 8 lines). > Hunk #3 succeeded at 2079 (offset 8 lines). > > With only Dimitry's patchesm this happens, to -rc4: > > $ cat ~/dev/001-ext4_fix-usless-declarations.diff | patch -p1 > patching file fs/ext4/ialloc.c > patching file fs/ext4/ioctl.c > Hunk #1 succeeded at 359 (offset 4 lines). > patching file fs/ext4/mballoc.c > patching file fs/ext4/move_extent.c > > $ cat ~/dev/002-ext4_fix-cpu_vs_disk-conversions.diff | patch --dry-run -p1 > patching file fs/ext4/extents.c > Hunk #4 FAILED at 4639. > 1 out of 4 hunks FAILED -- saving rejects to file fs/ext4/extents.c.rej > patching file fs/ext4/indirect.c > Hunk #1 succeeded at 1539 (offset 215 lines). > patching file fs/ext4/inode.c > patching file fs/ext4/mmp.c > patching file fs/ext4/namei.c > patching file fs/ext4/super.c > Hunk #1 succeeded at 1951 (offset -3 lines). > patching file fs/ext4/xattr.c > patching file include/trace/events/ext4.h > Hunk #1 succeeded at 1956 (offset 8 lines). > Hunk #2 succeeded at 2060 (offset 8 lines). > Hunk #3 succeeded at 2079 (offset 8 lines). I guess that is because Dmitry's patch is against dev branch of ext4 tree. Please applied my patch. I think it could fix the bug. That would be great if you could give this patch a try [1]. 1. http://patchwork.ozlabs.org/patch/233555/ Thanks, - Zheng ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: bisected! (WAS Re: s390x: kernel BUG at fs/ext4/inode.c:1591!) 2013-04-02 4:06 ` bisected! (WAS Re: s390x: kernel BUG at fs/ext4/inode.c:1591!) CAI Qian [not found] ` <alpine.DEB.2.10.1304012249440.5874@trent.utfs.org> @ 2013-04-02 10:01 ` Dmitry Monakhov [not found] ` <876098945.1097253.1364961617725.JavaMail.root@redhat.com> 1 sibling, 1 reply; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-02 10:01 UTC (permalink / raw) To: CAI Qian; +Cc: Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4 [-- Attachment #1: Type: text/plain, Size: 2852 bytes --] On Tue, 2 Apr 2013 00:06:24 -0400 (EDT), CAI Qian <caiqian@redhat.com> wrote: > Bisect indicated this is the culprit, > > 0e401101db49959f5783f6ee9e676124b5a183ac > ext4: fix memory leakage in mext_check_coverage Strange... It changes a bug in move_extent.c (e4defrag functionality) ASAIU you just previously stopped your bisecting process here. Right? Is this indeed a first bad commit? > > This following with Dmitry's debug patch applied, > > CAI Qian > > Ý 101.408610¨ ES cache assertation failed for inode: 753 es_cached ex Ý56/5/744 > 81/20¨ != found ex Ý56/5/3396400/0¨ retval 0 flags 5 > Ý 209.858899¨ ES cache assertation failed for inode: 384 es_cached ex Ý57/7/332 > 82/20¨ != found ex Ý57/7/3396400/0¨ retval 0 flags 5 > Ý 209.860656¨ ES cache assertation failed for inode: 384 es_cached ex Ý25/1/332 > 50/20¨ != found ex Ý25/1/0/0¨ retval 0 flags 0 > Ý 209.893587¨ ES cache assertation failed for inode: 384 es_cached ex Ý22/1/332 > 47/20¨ != found ex Ý22/1/34838/1000¨ retval 1 flags 0 > Ý 209.913482¨ ES cache assertation failed for inode: 384 es_cached ex Ý27/1/329 > 40/20¨ != found ex Ý27/1/0/0¨ retval 0 flags 0 > Ý 209.919950¨ ES cache assertation failed for inode: 384 es_cached ex Ý59/5/338 > 48/20¨ != found ex Ý59/5/3396400/0¨ retval 0 flags 5 > Ý 209.931856¨ ES cache assertation failed for inode: 384 es_cached ex Ý7/1/3292 > 0/20¨ != found ex Ý7/1/35879/20¨ retval 1 flags 43 > Ý 209.969282¨ ES cache assertation failed for inode: 384 es_cached ex Ý35/1/361 > 97/20¨ != found ex Ý35/1/36197/1000¨ retval 1 flags 0 > Ý 209.969290¨ ES cache assertation failed for inode: 384 es_cached ex Ý48/1/362 > 10/20¨ != found ex Ý48/1/0/0¨ retval 0 flags 0 > Ý 209.980724¨ ES cache assertation failed for inode: 384 es_cached ex Ý13/4/334 > 89/20¨ != found ex Ý13/4/2161372/0¨ retval 0 flags 5 > Ý 209.980744¨ ES cache assertation failed for inode: 384 es_cached ex Ý61/3/335 > 37/20¨ != found ex Ý61/3/3396400/0¨ retval 0 flags 5 > Ý 209.983848¨ ES cache assertation failed for inode: 384 es_cached ex Ý44/2/335 > 20/20¨ != found ex Ý44/2/36216/20¨ retval 2 flags 43 > Ý 210.020041¨ ES cache assertation failed for inode: 384 es_cached ex Ý61/3/341 > 91/20¨ != found ex Ý61/3/3396400/0¨ retval 0 flags 5 > Ý 210.050100¨ ES cache assertation failed for inode: 384 es_cached ex Ý22/11/34 > 565/20¨ != found ex Ý22/11/3396400/0¨ retval 0 flags 5 > Ý 210.053271¨ ES cache assertation failed for inode: 384 es_cached ex Ý15/1/334 > 90/20¨ != found ex Ý15/1/33579/1000¨ retval 1 flags 1 It does not looks like bigendian issue, actually I cant find any logical system in the log. The only thing I see is that es_cache is horribly out of sync with extent_tree. Please try this patch: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: disable-es_lookup_extent.patch --] [-- Type: text/x-patch, Size: 433 bytes --] diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index fe3337a..95d27cd 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -689,6 +689,7 @@ int ext4_es_lookup_extent(struct inode *inode, ext4_lblk_t lblk, trace_ext4_es_lookup_extent_enter(inode, lblk); es_debug("lookup extent in block %u\n", lblk); + return 0; tree = &EXT4_I(inode)->i_es_tree; read_lock(&EXT4_I(inode)->i_es_lock); [-- Attachment #3: Type: text/plain, Size: 3927 bytes --] It just disable es_cache lookup feature should. This should helps to determine whenever this is a es_cache issue or not. > Ý 210.053275¨ mpage_da_submit_io failed block=33490 != b_blocknr=33579 > Ý 210.053277¨ ino:384 lbkl:15, b_state=0x00001023, b_size=4096 > Ý 210.053320¨ ------------Ý cut here ¨------------ > Ý 210.053323¨ kernel BUG at fs/ext4/inode.c:1639! > Ý 210.053402¨ illegal operation: 0001 Ý#1¨ SMP > Ý 210.053405¨ Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast > ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipt > able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defra > g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tab > les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod dasd_eck > d_mod lcs dasd_mod qeth ctcm qdio ccwgroup fsm dm_mirror dm_region_hash dm_log d > m_mod > Ý 210.053434¨ CPU: 0 Not tainted 3.8.0-rc3+ #16 > Ý 210.053436¨ Process fsx (pid: 20565, task: 000000002c358000, ksp: 000000002c0 > 8f480) > Ý 210.053439¨ Krnl PSW : 0704f00180000000 00000000003033e8 (mpage_da_submit_io > 0x3d4/0x408) > Ý 210.053450¨ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 EA: > 3 > Krnl GPRS: 0000000000000015 0000000000000001 0000000000000030 00000000031b4508 > Ý 210.053455¨ 00000000003033e4 0000000000000000 0000000000001000 000 > 7ffff00001000 > Ý 210.053457¨ 000000002c08fa98 000003d100a8c6c0 000000002c08fb68 000 > 000000000000f > Ý 210.053460¨ 00000000000082d2 000000002204d068 00000000003033e4 000 > 000002c08f970 > Ý 210.053473¨ Krnl Code: 00000000003033d8: c02000215447 larl %r2,72dc > 66 > 00000000003033de: c0e50016788f brasl %r14,5d24fc > #00000000003033e4: a7f40001 brc 15,3033e6 > >00000000003033e8: a7f40001 brc 15,3033ea > 00000000003033ec: a7f40001 brc 15,3033ee > 00000000003033f0: 4120f0e8 la %r2,232(%r15) > 00000000003033f4: a7180000 lhi %r1,0 > 00000000003033f8: 5010f0d8 st %r1,216(%r15) > Ý 210.053497¨ Call Trace: > Ý 210.053498¨ (Ý<00000000003033e4>¨ mpage_da_submit_io+0x3d0/0x408) > Ý 210.053501¨ Ý<0000000000309a48>¨ mpage_da_map_and_submit+0x150/0x41c > Ý 210.053505¨ Ý<000000000030a212>¨ write_cache_pages_da+0x4fe/0x530 > Ý 210.053509¨ Ý<000000000030a584>¨ ext4_da_writepages+0x340/0x628 > Ý 210.053512¨ Ý<00000000002024d2>¨ __filemap_fdatawrite_range+0x6e/0x7c > Ý 210.053518¨ Ý<00000000002025fc>¨ filemap_write_and_wait_range+0x54/0x8c > Ý 210.053521¨ Ý<00000000002fe0f8>¨ ext4_sync_file+0x7c/0x3d8 > Ý 210.053524¨ Ý<000000000023c932>¨ SyS_msync+0x14e/0x1d8 > Ý 210.053528¨ Ý<00000000005de66e>¨ sysc_tracego+0x14/0x1a > Ý 210.053533¨ Ý<000003fffd0e1240>¨ 0x3fffd0e1240 > Ý 210.053536¨ Last Breaking-Event-Address: > Ý 210.053537¨ Ý<00000000003033e4>¨ mpage_da_submit_io+0x3d0/0x408 > Ý 210.053540¨ > Ý 210.053542¨ ---Ý end trace f387176e9fcb98d0 ¨--- > Ý 210.053546¨ ------------Ý cut here ¨------------ > Ý 210.053548¨ WARNING: at kernel/exit.c:713 > Ý 210.053550¨ Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast > ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipt > able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defra > g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tab > les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod dasd_eck > d_mod lcs dasd_mod qeth ctcm qdio ccwgroup fsm dm_mirror dm_region_hash dm_log d > m_mod > Ý 210.053571¨ CPU: 0 Tainted: G D 3.8.0-rc3+ #16 ^ permalink raw reply related [flat|nested] 42+ messages in thread
[parent not found: <876098945.1097253.1364961617725.JavaMail.root@redhat.com>]
* Re: bisected! (WAS Re: s390x: kernel BUG at fs/ext4/inode.c:1591!) [not found] ` <876098945.1097253.1364961617725.JavaMail.root@redhat.com> @ 2013-04-03 7:14 ` CAI Qian 2013-04-03 7:51 ` Dmitry Monakhov 2013-04-03 8:09 ` Lukáš Czerner 1 sibling, 1 reply; 42+ messages in thread From: CAI Qian @ 2013-04-03 7:14 UTC (permalink / raw) To: Dmitry Monakhov Cc: Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4, Lukas Czerner, stable > > [Text Documents:disable-es_lookup_extent.patch] With this patch, I cannot reproduce it any more. CAI Qian ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: bisected! (WAS Re: s390x: kernel BUG at fs/ext4/inode.c:1591!) 2013-04-03 7:14 ` CAI Qian @ 2013-04-03 7:51 ` Dmitry Monakhov 0 siblings, 0 replies; 42+ messages in thread From: Dmitry Monakhov @ 2013-04-03 7:51 UTC (permalink / raw) To: CAI Qian Cc: Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4, Lukas Czerner, stable On Wed, 3 Apr 2013 03:14:44 -0400 (EDT), CAI Qian <caiqian@redhat.com> wrote: > > > > [Text Documents:disable-es_lookup_extent.patch] > With this patch, I cannot reproduce it any more. Ok that is second confirmation that bug caused by issue in es_cache, This is not a fix though. So still try to investigate that. > > CAI Qian ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: bisected! (WAS Re: s390x: kernel BUG at fs/ext4/inode.c:1591!) [not found] ` <876098945.1097253.1364961617725.JavaMail.root@redhat.com> 2013-04-03 7:14 ` CAI Qian @ 2013-04-03 8:09 ` Lukáš Czerner 1 sibling, 0 replies; 42+ messages in thread From: Lukáš Czerner @ 2013-04-03 8:09 UTC (permalink / raw) To: CAI Qian Cc: Dmitry Monakhov, Theodore Ts'o, LKML, linux-s390, Steve Best, linux-ext4, Lukas Czerner, stable [-- Attachment #1: Type: TEXT/PLAIN, Size: 8819 bytes --] On Wed, 3 Apr 2013, CAI Qian wrote: > Date: Wed, 3 Apr 2013 00:00:17 -0400 (EDT) > From: CAI Qian <caiqian@redhat.com> > To: Dmitry Monakhov <dmonakhov@openvz.org> > Cc: Theodore Ts'o <tytso@mit.edu>, LKML <linux-kernel@vger.kernel.org>, > linux-s390 <linux-s390@vger.kernel.org>, Steve Best <sbest@redhat.com>, > linux-ext4@vger.kernel.org, Lukas Czerner <lczerner@redhat.com>, > stable@vger.kernel.org > Subject: Re: bisected! (WAS Re: s390x: kernel BUG at fs/ext4/inode.c:1591!) > > > > ----- Original Message ----- > > From: "Dmitry Monakhov" <dmonakhov@openvz.org> > > To: "CAI Qian" <caiqian@redhat.com> > > Cc: "Theodore Ts'o" <tytso@mit.edu>, "LKML" <linux-kernel@vger.kernel.org>, "linux-s390" > > <linux-s390@vger.kernel.org>, "Steve Best" <sbest@redhat.com>, linux-ext4@vger.kernel.org > > Sent: Tuesday, April 2, 2013 6:01:36 PM > > Subject: Re: bisected! (WAS Re: s390x: kernel BUG at fs/ext4/inode.c:1591!) > > > > On Tue, 2 Apr 2013 00:06:24 -0400 (EDT), CAI Qian <caiqian@redhat.com> wrote: > > > Bisect indicated this is the culprit, > > > > > > 0e401101db49959f5783f6ee9e676124b5a183ac > > > ext4: fix memory leakage in mext_check_coverage > > Strange... > > It changes a bug in move_extent.c (e4defrag functionality) > > ASAIU you just previously stopped your bisecting process here. Right? > > Is this indeed a first bad commit? > Hmm, bisect went wrong in the first place. Now double-confirmed this is > the culprit, > > 4f42f80a8f08d4c3f52c4267361241885d5dee3a > ext4: use s_extent_max_zeroout_kb value as number of kb With this commit we're zeroing parts of uninitialized extents when converting uninitialized extents to initialized as we should. This is unlikely to be real cause, though it probably uncover some another bug which we could not notice before. -Lukas > > > > > > > This following with Dmitry's debug patch applied, > > > > > > CAI Qian > > > > > > Ý 101.408610¨ ES cache assertation failed for inode: 753 es_cached ex > > > Ý56/5/744 > > > 81/20¨ != found ex Ý56/5/3396400/0¨ retval 0 flags 5 > > > Ý 209.858899¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý57/7/332 > > > 82/20¨ != found ex Ý57/7/3396400/0¨ retval 0 flags 5 > > > Ý 209.860656¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý25/1/332 > > > 50/20¨ != found ex Ý25/1/0/0¨ retval 0 flags 0 > > > Ý 209.893587¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý22/1/332 > > > 47/20¨ != found ex Ý22/1/34838/1000¨ retval 1 flags 0 > > > Ý 209.913482¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý27/1/329 > > > 40/20¨ != found ex Ý27/1/0/0¨ retval 0 flags 0 > > > Ý 209.919950¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý59/5/338 > > > 48/20¨ != found ex Ý59/5/3396400/0¨ retval 0 flags 5 > > > Ý 209.931856¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý7/1/3292 > > > 0/20¨ != found ex Ý7/1/35879/20¨ retval 1 flags 43 > > > Ý 209.969282¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý35/1/361 > > > 97/20¨ != found ex Ý35/1/36197/1000¨ retval 1 flags 0 > > > Ý 209.969290¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý48/1/362 > > > 10/20¨ != found ex Ý48/1/0/0¨ retval 0 flags 0 > > > Ý 209.980724¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý13/4/334 > > > 89/20¨ != found ex Ý13/4/2161372/0¨ retval 0 flags 5 > > > Ý 209.980744¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý61/3/335 > > > 37/20¨ != found ex Ý61/3/3396400/0¨ retval 0 flags 5 > > > Ý 209.983848¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý44/2/335 > > > 20/20¨ != found ex Ý44/2/36216/20¨ retval 2 flags 43 > > > Ý 210.020041¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý61/3/341 > > > 91/20¨ != found ex Ý61/3/3396400/0¨ retval 0 flags 5 > > > Ý 210.050100¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý22/11/34 > > > 565/20¨ != found ex Ý22/11/3396400/0¨ retval 0 flags 5 > > > Ý 210.053271¨ ES cache assertation failed for inode: 384 es_cached ex > > > Ý15/1/334 > > > 90/20¨ != found ex Ý15/1/33579/1000¨ retval 1 flags 1 > > It does not looks like bigendian issue, actually I cant find any logical > > system in the log. The only thing I see is that es_cache is > > horribly out of sync with extent_tree. > > Please try this patch: > I'll test that shortly. > CAI Qian > > > > > > [Text Documents:disable-es_lookup_extent.patch] > > > > > > It just disable es_cache lookup feature should. This should helps to > > determine whenever this is a es_cache issue or not. > > > Ý 210.053275¨ mpage_da_submit_io failed block=33490 != b_blocknr=33579 > > > Ý 210.053277¨ ino:384 lbkl:15, b_state=0x00001023, b_size=4096 > > > Ý 210.053320¨ ------------Ý cut here ¨------------ > > > Ý 210.053323¨ kernel BUG at fs/ext4/inode.c:1639! > > > Ý 210.053402¨ illegal operation: 0001 Ý#1¨ SMP > > > Ý 210.053405¨ Modules linked in: nf_conntrack_netbios_ns > > > nf_conntrack_broadcast > > > ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 > > > nf_defrag_ipv6 ipt > > > able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 > > > nf_defra > > > g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter > > > ip6_tab > > > les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod > > > dasd_eck > > > d_mod lcs dasd_mod qeth ctcm qdio ccwgroup fsm dm_mirror dm_region_hash > > > dm_log d > > > m_mod > > > Ý 210.053434¨ CPU: 0 Not tainted 3.8.0-rc3+ #16 > > > Ý 210.053436¨ Process fsx (pid: 20565, task: 000000002c358000, ksp: > > > 000000002c0 > > > 8f480) > > > Ý 210.053439¨ Krnl PSW : 0704f00180000000 00000000003033e8 > > > (mpage_da_submit_io > > > 0x3d4/0x408) > > > Ý 210.053450¨ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 > > > PM:0 EA: > > > 3 > > > Krnl GPRS: 0000000000000015 0000000000000001 0000000000000030 > > > 00000000031b4508 > > > Ý 210.053455¨ 00000000003033e4 0000000000000000 > > > 0000000000001000 000 > > > 7ffff00001000 > > > Ý 210.053457¨ 000000002c08fa98 000003d100a8c6c0 > > > 000000002c08fb68 000 > > > 000000000000f > > > Ý 210.053460¨ 00000000000082d2 000000002204d068 > > > 00000000003033e4 000 > > > 000002c08f970 > > > Ý 210.053473¨ Krnl Code: 00000000003033d8: c02000215447 larl > > > %r2,72dc > > > 66 > > > 00000000003033de: c0e50016788f brasl %r14,5d24fc > > > #00000000003033e4: a7f40001 brc 15,3033e6 > > > >00000000003033e8: a7f40001 brc 15,3033ea > > > 00000000003033ec: a7f40001 brc 15,3033ee > > > 00000000003033f0: 4120f0e8 la %r2,232(%r15) > > > 00000000003033f4: a7180000 lhi %r1,0 > > > 00000000003033f8: 5010f0d8 st %r1,216(%r15) > > > Ý 210.053497¨ Call Trace: > > > Ý 210.053498¨ (Ý<00000000003033e4>¨ mpage_da_submit_io+0x3d0/0x408) > > > Ý 210.053501¨ Ý<0000000000309a48>¨ mpage_da_map_and_submit+0x150/0x41c > > > Ý 210.053505¨ Ý<000000000030a212>¨ write_cache_pages_da+0x4fe/0x530 > > > Ý 210.053509¨ Ý<000000000030a584>¨ ext4_da_writepages+0x340/0x628 > > > Ý 210.053512¨ Ý<00000000002024d2>¨ __filemap_fdatawrite_range+0x6e/0x7c > > > Ý 210.053518¨ Ý<00000000002025fc>¨ filemap_write_and_wait_range+0x54/0x8c > > > Ý 210.053521¨ Ý<00000000002fe0f8>¨ ext4_sync_file+0x7c/0x3d8 > > > Ý 210.053524¨ Ý<000000000023c932>¨ SyS_msync+0x14e/0x1d8 > > > Ý 210.053528¨ Ý<00000000005de66e>¨ sysc_tracego+0x14/0x1a > > > Ý 210.053533¨ Ý<000003fffd0e1240>¨ 0x3fffd0e1240 > > > Ý 210.053536¨ Last Breaking-Event-Address: > > > Ý 210.053537¨ Ý<00000000003033e4>¨ mpage_da_submit_io+0x3d0/0x408 > > > Ý 210.053540¨ > > > Ý 210.053542¨ ---Ý end trace f387176e9fcb98d0 ¨--- > > > Ý 210.053546¨ ------------Ý cut here ¨------------ > > > Ý 210.053548¨ WARNING: at kernel/exit.c:713 > > > Ý 210.053550¨ Modules linked in: nf_conntrack_netbios_ns > > > nf_conntrack_broadcast > > > ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 > > > nf_defrag_ipv6 ipt > > > able_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 > > > nf_defra > > > g_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter > > > ip6_tab > > > les iptable_filter ip_tables sg qeth_l2 vmur xfs libcrc32c dasd_fba_mod > > > dasd_eck > > > d_mod lcs dasd_mod qeth ctcm qdio ccwgroup fsm dm_mirror dm_region_hash > > > dm_log d > > > m_mod > > > Ý 210.053571¨ CPU: 0 Tainted: G D 3.8.0-rc3+ #16 > > > ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2013-04-22 10:05 UTC | newest]
Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <863434221.7624846.1364452822093.JavaMail.root@redhat.com>
2013-03-28 6:40 ` s390x: kernel BUG at fs/ext4/inode.c:1591! CAI Qian
2013-03-28 6:40 ` CAI Qian
2013-03-28 9:44 ` CAI Qian
2013-03-28 9:44 ` CAI Qian
2013-03-28 12:05 ` Theodore Ts'o
2013-03-28 14:56 ` Dmitry Monakhov
2013-03-29 8:53 ` CAI Qian
2013-03-29 10:08 ` Dmitry Monakhov
2013-03-29 9:27 ` CAI Qian
2013-04-01 6:07 ` Dmitry Monakhov
2013-04-01 6:07 ` Dmitry Monakhov
2013-04-01 6:30 ` CAI Qian
2013-04-01 6:30 ` CAI Qian
2013-04-01 6:56 ` Dmitry Monakhov
2013-04-01 6:56 ` Dmitry Monakhov
2013-04-02 4:06 ` bisected! (WAS Re: s390x: kernel BUG at fs/ext4/inode.c:1591!) CAI Qian
[not found] ` <alpine.DEB.2.10.1304012249440.5874@trent.utfs.org>
2013-04-02 9:47 ` s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) Dmitry Monakhov
2013-04-02 12:33 ` Zheng Liu
[not found] ` <alpine.DEB.2.10.1304021202100.13746@trent.utfs.org>
2013-04-02 19:49 ` Dmitry Monakhov
2013-04-02 19:49 ` Dmitry Monakhov
[not found] ` <alpine.DEB.2.10.1304020955280.13746@trent.utfs.org>
2013-04-02 17:19 ` Dmitry Monakhov
[not found] ` <alpine.DEB.2.10.1304021430480.13746@trent.utfs.org>
2013-04-02 22:05 ` Dmitry Monakhov
[not found] ` <alpine.DEB.2.10.1304021611020.13746@trent.utfs.org>
2013-04-03 8:52 ` Dmitry Monakhov
2013-04-03 9:53 ` Dmitry Monakhov
2013-04-03 10:22 ` Zheng Liu
2013-04-03 12:20 ` [PATCH] ext4: fix a big-endian bug when an extent is zeroed out Theodore Ts'o
2013-04-03 12:29 ` Dmitry Monakhov
2013-04-03 14:34 ` Eric Whitney
2013-04-03 14:41 ` Theodore Ts'o
2013-04-03 15:23 ` Florian Fainelli
2013-04-03 15:23 ` Florian Fainelli
2013-04-09 3:05 ` CAI Qian
2013-04-20 15:19 ` Theodore Ts'o
2013-04-22 3:40 ` CAI Qian
2013-04-22 10:04 ` Christian Borntraeger
2013-04-03 11:02 ` s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!) Dmitry Monakhov
[not found] ` <alpine.DEB.2.10.1304030935230.13746@trent.utfs.org>
2013-04-03 16:50 ` Dmitry Monakhov
2013-04-03 16:52 ` Zheng Liu
2013-04-02 10:01 ` bisected! (WAS Re: s390x: kernel BUG at fs/ext4/inode.c:1591!) Dmitry Monakhov
[not found] ` <876098945.1097253.1364961617725.JavaMail.root@redhat.com>
2013-04-03 7:14 ` CAI Qian
2013-04-03 7:51 ` Dmitry Monakhov
2013-04-03 8:09 ` Lukáš Czerner
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.