== Comment: #0 - Mahesh M. Hiremath <maheshhi.com> - 2012-12-28 18:57:44 == While running Filesystem Stress Test(fsracer),below call trace was generated. Dec 22 20:31:53 miz10 kernel: [ 879.191118] ------------[ cut here ]------------ Dec 22 20:31:53 miz10 kernel: [ 879.191120] WARNING: at fs/ext4/inode.c:362 Dec 22 20:31:53 miz10 kernel: [ 879.191122] Modules linked in: reiserfs nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables ibmveth ibmvscsic scsi_transport_srp scsi_tgt Dec 22 20:31:53 miz10 kernel: [ 879.191142] NIP: c0000000002d149c LR: c0000000002d1498 CTR: c0000000003f2f90 Dec 22 20:31:53 miz10 kernel: [ 879.191144] REGS: c00000013953b250 TRAP: 0700 Not tainted (3.6.10-4.fc18.ppc64p7) Dec 22 20:31:53 miz10 kernel: [ 879.191144] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28044884 XER: 20000000 Dec 22 20:31:53 miz10 kernel: [ 879.191149] SOFTE: 1 Dec 22 20:31:53 miz10 kernel: [ 879.191150] CFAR: c0000000002f7658 Dec 22 20:31:53 miz10 kernel: [ 879.191151] TASK = c00000000532f400[14704] 'fsstress' THREAD: c000000139538000 CPU: 0 Dec 22 20:31:53 miz10 kernel: [ 879.191151] GPR00: c0000000002d1498 c00000013953b4d0 c0000000012b3e68 0000000000000069 Dec 22 20:31:53 miz10 kernel: [ 879.191151] GPR04: 0000000000000000 0000000000000000 0000000000000030 000000000000000a Dec 22 20:31:53 miz10 kernel: [ 879.191151] GPR08: 0000000000000001 0000000000000000 0000000000000000 0000000000000000 Dec 22 20:31:53 miz10 kernel: [ 879.191151] GPR12: 0000000028044882 c00000000eda0000 0000000000000000 0000000000000000 Dec 22 20:31:53 miz10 kernel: [ 879.191151] GPR16: 0000000000000001 c0000001260e0410 0000000000000002 c000000124cb9260 Dec 22 20:31:53 miz10 kernel: [ 879.191151] GPR20: c000000124cb93a8 c00000013953b7b0 c00000013953bb10 c00000013953b968 Dec 22 20:31:53 miz10 kernel: [ 879.191151] GPR24: 00007fffffffffff 0000000000000001 c000000138784400 0000000000000001 Dec 22 20:31:53 miz10 kernel: [ 879.191151] GPR28: 0000000000000040 0000000000000040 c000000001234818 c000000124cb9260 Dec 22 20:31:53 miz10 kernel: [ 879.191173] NIP [c0000000002d149c] .ext4_da_update_reserve_space+0x2bc/0x2e0 Dec 22 20:31:53 miz10 kernel: [ 879.191174] LR [c0000000002d1498] .ext4_da_update_reserve_space+0x2b8/0x2e0 Dec 22 20:31:53 miz10 kernel: [ 879.191175] Call Trace: Dec 22 20:31:53 miz10 kernel: [ 879.191177] [c00000013953b4d0] [c0000000002d1498] .ext4_da_update_reserve_space+0x2b8/0x2e0 (unreliable) Dec 22 20:31:53 miz10 kernel: [ 879.191180] [c00000013953b580] [c0000000002d162c] .ext4_map_blocks+0x16c/0x2f0 Dec 22 20:31:53 miz10 kernel: [ 879.191182] [c00000013953b630] [c0000000002d7000] .mpage_da_map_and_submit+0xc0/0x4e0 Dec 22 20:31:53 miz10 kernel: [ 879.191183] [c00000013953b700] [c0000000002d7808] .write_cache_pages_da+0x2c8/0x420 Dec 22 20:31:53 miz10 kernel: [ 879.191185] [c00000013953b880] [c0000000002d7c54] .ext4_da_writepages+0x2f4/0x650 Dec 22 20:31:53 miz10 kernel: [ 879.191188] [c00000013953ba10] [c0000000001af340] .do_writepages+0x60/0xc0 Dec 22 20:31:53 miz10 kernel: [ 879.191190] [c00000013953baa0] [c0000000001a0a98] .__filemap_fdatawrite_range+0x78/0xa0 Dec 22 20:31:53 miz10 kernel: [ 879.191193] [c00000013953bb70] [c0000000001a0c64] .filemap_write_and_wait_range+0x84/0xd0 Dec 22 20:31:53 miz10 kernel: [ 879.191194] [c00000013953bc10] [c0000000002cafcc] .ext4_sync_file+0x8c/0x500 Dec 22 20:31:53 miz10 kernel: [ 879.191197] [c00000013953bd00] [c00000000025bac4] .do_fsync+0x84/0xe0 Dec 22 20:31:53 miz10 kernel: [ 879.191199] [c00000013953bdb0] [c00000000025c0f8] .SyS_fdatasync+0x28/0x40 Dec 22 20:31:53 miz10 kernel: [ 879.191202] [c00000013953be30] [c000000000009854] syscall_exit+0x0/0x94 Dec 22 20:31:53 miz10 kernel: [ 879.191203] Instruction dump: Dec 22 20:31:53 miz10 kernel: [ 879.191204] 7c0004ac 39400000 994d0244 4bfffe3c e8de8010 e87f0028 e89e80a8 e8be80d0 Dec 22 20:31:53 miz10 kernel: [ 879.191208] e8ff0040 38c60070 4802613d 60000000 <0fe00000> 813f0274 815f0270 913f0278 Dec 22 20:31:53 miz10 kernel: [ 879.191211] ---[ end trace ab64d45b9055bad5 ]--- Dec 22 20:32:10 miz10 kernel: [ 896.099093] EXT4-fs (sdb): ext4_da_update_reserve_space: ino 122894, allocated 1 with only 0 reserved metadata blocks ------- Steps to reproduce --- 1.Download ltp latest version and install it on your test system 2.This test suite is a part of LTP ($LTPROOT/testcases/kernel/fs/fsstress) 3.Create about 4 partitions in a spare hard disk by using fdisk of size > 4 GB. 4.Make different file systems(ext2,ext3,ext4,reiserfs) on these 4 partitions. 5.Create four dicretories on / (for example : mkdir /ext2 /ext3 /ext4 /reiserfs) 6.Mount the partitions created on the spare disk to these directories based on partion type & respective name 7.Give 777 permissions for these 4 directories by issuing chmod 777 on each one 8.Now run as below for each directory 9.nohup ./fsstress ?d /ext2 ?l 0 ?n 1000 ?p 1000 ?r & 10.nohup ./fsstress ?d /ext3 ?l 0 ?n 1000 ?p 1000 ?r & 11.nohup ./fsstress ?d /ext4 ?l 0 ?n 1000 ?p 1000 ?r & 12.nohup ./fsstress ?d /reiserfs ?l 0 ?n 1000 ?p 1000 ?r & --- Other Details --- [root@miz10 ~]# uname -a Linux miz10.austin.ibm.com 3.6.10-4.fc18.ppc64p7 #1 SMP Wed Dec 12 16:08:02 MST 2012 ppc64 ppc64 ppc64 GNU/Linux Note: Attached /var/log/message file for reference. Thanks, Mahesh == Comment: #1 - Mahesh M. Hiremath <maheshhi.com> - 2012-12-28 18:58:40 ==
Created attachment 703859 [details] /var/log/message
------- Comment From onmahaja.com 2013-03-04 06:55 EDT------- RedHat, Any updates on this ?
Does this still happen on 3.8 ?
------- Comment From chavez.com 2013-05-20 15:30 EDT------- I verifed the same in f19 by running 5 fsstress in 5 diffrent filesystem. and it works absolutly fine, no call trace has been generated. It is fixed in F19, we can close as fixed.
------- Comment From sanpatr1.com 2013-05-21 12:29 EDT------- (In reply to comment #11) > I verifed the same in f19 by running 5 fsstress in 5 diffrent filesystem. > and it works absolutly fine, no call trace has been generated. It is fixed > in F19, we can close as fixed. Kernel version, in which it is got fixed is Linux localhost.localdomain 3.9.0-301.fc19.ppc64p7