lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130223000955.GA3231@wallace>
Date:	Fri, 22 Feb 2013 19:09:56 -0500
From:	Eric Whitney <enwlinux@...il.com>
To:	linux-ext4@...r.kernel.org
Cc:	tytso@....edu
Subject: ext4 xfstests results for 3.8 on Pandaboard ES (ARM)

Here are the results of a set of xfstests runs on a Pandaboard ES running a
3.8 kernel.  The test system was equipped with a USB-attached SATA HDD.  The
test filesystems were located on the HDD.  The nine test scenarios were as
defined by xfstests-bld.

The results I reported previously for 3.8-rc6 were for the tests in the
xfstests "quick" group.  These results are for the "auto" group, which is
rather larger. They agree well with a parallel run made on an x86-64 KVM
guest, and with the exception of one broken xfstest (noted below), there's
nothing obviously ARM-specific to report.

Regards,
Eric

e2fsprogs (master, 1.43-WIP): fca8b1b241
xfstests: e5f1a13792

FSTESTCFG=all
FSTESTSET="-g auto"

BEGIN TEST: Ext4 4k block Thu Feb 21 12:56:03 EST 2013
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 068 069 070 074 075 076
 077 079 083 088 089 091 100 105 112 113 117 120 123 124 125 126 127 128 129
 130 131 132 133 135 141 169 184 192 193 198 204 207 208 209 210 211 212 213
 214 215 219 221 223 224 225 226 228 230 231 232 233 234 235 236 237 239 240
 243 245 246 247 248 249 255 256 257 258 263 269 270 271 272 273 274 275 277
 280 285 289 294
Failures: 125 274
END TEST: Ext4 4k block Thu Feb 21 15:40:44 EST 2013

Xfstest 125 failed because there's a bug in the test.  It defines O_DIRECT
improperly for ARM (patch pending, and the test succeeds when patched).  This
is the case for all following instances of 125 below as well.


BEGIN TEST: Ext4 4k block w/nodelalloc, no flex_bg, and no extents Thu Feb 21
15:41:27 EST 2013
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 068 069 070 074 075 076
 077 079 083 088 089 091 100 105 112 113 117 120 123 124 125 126 127 128 129
 130 131 132 133 135 141 169 184 192 193 198 204 207 208 209 210 211 212 215
 219 221 224 225 226 230 231 232 233 234 235 236 237 239 240 245 246 247 248
 249 257 258 263 269 270 271 272 273 275 277 280 285 289 294
Failures: 125 285
END TEST: Ext4 4k block w/nodelalloc, no flex_bg, and no extents Thu Feb 21
 17:24:32 EST 2013

Xfstest 285 fails reliably for me on both ARM and x86-64 and only in this test
scenario.  I see the same failure on 3.7, so it's not a regression (however,
this failure doesn't appear in Ted's early 3.8-rc results).

    --- 285.out	2013-02-19 15:58:25.110665500 -0500
    +++ 285.out.bad	2013-02-21 17:23:45.156519882 -0500
    @@ -1 +1,3 @@
     QA output created by 285
    +seek sanity check failed!


BEGIN TEST: Ext4 4k block w/ no journal Thu Feb 21 17:24:38 EST 2013
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 069 070 074 075 076 077
 079 083 088 089 091 100 105 112 113 117 120 123 124 125 126 127 128 129 130
 131 132 133 135 141 169 184 192 193 198 204 207 208 209 210 211 212 213 214
 215 219 221 223 224 225 226 228 230 231 232 233 234 235 236 237 239 240 243
 245 246 247 248 249 255 256 257 258 263 269 270 271 272 273 274 275 277 285
 289 294
Failures: 125 274
END TEST: Ext4 4k block w/ no journal Thu Feb 21 19:57:53 EST 2013

BEGIN TEST: Ext4 1k block Thu Feb 21 19:58:29 EST 2013
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 068 069 070 074 075 076
 077 079 083 088 089 091 100 105 112 113 117 120 123 124 125 126 127 128 129
 130 131 132 133 135 141 169 184 192 193 198 204 207 208 209 210 211 212 213
 214 215 219 221 223 224 225 226 228 230 231 232 233 234 235 236 237 239 240
 243 245 246 247 248 249 255 256 257 258 263 269 270 271 272 273 274 275 277
 280 285 289 294
Failures: 089 125 274
END TEST: Ext4 1k block Thu Feb 21 21:37:34 EST 2013

Xfstest 089 failed because the test segfaulted.  I've never seen this in many
test runs on earlier kernel versions, and was unable to reproduce it in 10
trials on 3.8.


BEGIN TEST: Ext4 4k block w/nodelalloc and no flex_bg Thu Feb 21 21:37:41 EST
2013
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 068 069 070 074 075 076
 077 079 083 088 089 091 100 105 112 113 117 120 123 124 125 126 127 128 129
 130 131 132 133 135 141 169 184 192 193 198 204 207 208 209 210 211 212 213
 214 215 219 221 223 224 225 226 228 230 231 232 233 234 235 236 237 239 240
 243 245 246 247 248 249 255 256 257 258 263 269 270 271 272 273 274 275 277
 280 285 289 294
Failures: 125 223 274
END TEST: Ext4 4k block w/nodelalloc and no flex_bg Thu Feb 21 23:15:59 EST 2013

BEGIN TEST: Ext4 4k block w/metadata_csum Thu Feb 21 23:16:07 EST 2013
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 068 069 070 074 075 076
 077 079 083 088 089 091 100 105 112 113 117 120 123 124 125 126 127 128 129
 130 131 132 133 135 141 169 184 192 193 198 204 207 208 209 210 211 212 213
 214 215 219 221 223 224 225 226 228 230 231 232 233 234 235 236 237 239 240
 243 245 246 247 248 249 255 256 257 258 263 269 270 271 272 273 274 275 277
 280 285 289 294
Failures: 125 274
END TEST: Ext4 4k block w/metadata_csum Fri Feb 22 00:54:18 EST 2013

Xfstest 127 resulted in a few instances of this in the kernel log:

kernel: [39512.460052] EXT4-fs (sda3): ext4_da_update_reserve_space: ino 1133, allocated 1 with only 0 reserved metadata blocks
kernel: [39512.460052] 
kernel: [39512.460052] ------------[ cut here ]------------
kernel: [39512.464935] WARNING: at fs/ext4/inode.c:362 ext4_da_update_reserve_space+0x214/0x280()
kernel: [39512.473266] Modules linked in:
kernel: [39512.476562] [<c0016d18>] (unwind_backtrace+0x0/0x104) from [<c059f448>] (dump_stack+0x20/0x24)
kernel: [39512.485656] [<c059f448>] (dump_stack+0x20/0x24) from [<c0037c68>] (warn_slowpath_common+0x5c/0x74)
kernel: [39512.495117] [<c0037c68>] (warn_slowpath_common+0x5c/0x74) from [<c0037cac>] (warn_slowpath_null+0x2c/0x34)
kernel: [39512.505279] [<c0037cac>] (warn_slowpath_null+0x2c/0x34) from [<c01affd8>] (ext4_da_update_reserve_space+0x214/0x280)
kernel: [39512.516418] [<c01affd8>] (ext4_da_update_reserve_space+0x214/0x280) from [<c01dd660>] (ext4_ext_map_blocks+0xe64/0x153c)
kernel: [39512.527862] [<c01dd660>] (ext4_ext_map_blocks+0xe64/0x153c) from [<c01b0108>] (ext4_map_blocks+0xc4/0x230)
kernel: [39512.538024] [<c01b0108>] (ext4_map_blocks+0xc4/0x230) from [<c01b4750>] (mpage_da_map_and_submit+0xa0/0x598)
kernel: [39512.548370] [<c01b4750>] (mpage_da_map_and_submit+0xa0/0x598) from [<c01b512c>] (write_cache_pages_da+0x3fc/0x428)
kernel: [39512.559265] [<c01b512c>] (write_cache_pages_da+0x3fc/0x428) from [<c01b5404>] (ext4_da_writepages+0x2ac/0x564)
kernel: [39512.569793] [<c01b5404>] (ext4_da_writepages+0x2ac/0x564) from [<c00e3880>] (do_writepages+0x34/0x48)
kernel: [39512.579498] [<c00e3880>] (do_writepages+0x34/0x48) from [<c00d9b18>] (__filemap_fdatawrite_range+0x5c/0x64)
kernel: [39512.589752] [<c00d9b18>] (__filemap_fdatawrite_range+0x5c/0x64) from [<c00d9c44>] (filemap_write_and_wait_range+0x50/0x7c)
kernel: [39512.601379] [<c00d9c44>] (filemap_write_and_wait_range+0x50/0x7c) from [<c01ab224>] (ext4_sync_file+0x80/0x354)
kernel: [39512.611999] [<c01ab224>] (ext4_sync_file+0x80/0x354) from [<c0144ee0>] (vfs_fsync+0x4c/0x5c)
kernel: [39512.620880] [<c0144ee0>] (vfs_fsync+0x4c/0x5c) from [<c01056f8>] (sys_msync+0x158/0x1d0)
kernel: [39512.629425] [<c01056f8>] (sys_msync+0x158/0x1d0) from [<c000e3c0>] (ret_fast_syscall+0x0/0x3c)
kernel: [39512.638488] ---[ end trace fd1fce56cb4aa3a9 ]---


BEGIN TEST: Ext4 4k block w/dioread_nolock Fri Feb 22 00:54:19 EST 2013
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 068 069 070 074 075 076
 077 079 083 088 089 091 100 105 112 113 117 120 123 124 125 126 127 128 129
 130 131 132 133 135 141 169 184 192 193 198 204 207 208 209 210 211 212 213
 214 215 219 221 223 224 225 226 228 230 231 232 233 234 235 236 237 239 240
 243 245 246 247 248 249 255 256 257 258 263 269 270 271 272 273 274 275 277
 280 285 289 294
Failures: 125 233 274
END TEST: Ext4 4k block w/dioread_nolock Fri Feb 22 03:30:26 EST 2013

Xfstest 113 produced a lockdep warning previously reported in my 3.8-rc6 results and explained by Jan Kara.

Xfstest 272 resulted in a few instances of this in the kernel log:
kernel: [51945.172241] WARNING: at fs/ext4/extents.c:4540 ext4_convert_unwritten_extents+0x11c/0x198()
kernel: [51945.181030] Modules linked in:
kernel: [51945.184265] [<c0016d18>] (unwind_backtrace+0x0/0x104) from [<c059f448>] (dump_stack+0x20/0x24)
kernel: [51945.193359] [<c059f448>] (dump_stack+0x20/0x24) from [<c0037c68>] (warn_slowpath_common+0x5c/0x74)
kernel: [51945.202850] [<c0037c68>] (warn_slowpath_common+0x5c/0x74) from [<c0037cac>] (warn_slowpath_null+0x2c/0x34)
kernel: [51945.213012] [<c0037cac>] (warn_slowpath_null+0x2c/0x34) from [<c01de664>] (ext4_convert_unwritten_extents+0x11c/0x198)
kernel: [51945.224304] [<c01de664>] (ext4_convert_unwritten_extents+0x11c/0x198) from [<c01b64f0>] (ext4_do_flush_completed_IO+0x1a4/0x2fc)
kernel: [51945.236450] [<c01b64f0>] (ext4_do_flush_completed_IO+0x1a4/0x2fc) from [<c01b6668>] (ext4_end_io_work+0x20/0x24)
kernel: [51945.247131] [<c01b6668>] (ext4_end_io_work+0x20/0x24) from [<c00562c4>] (process_one_work+0x1cc/0x58c)
kernel: [51945.256927] [<c00562c4>] (process_one_work+0x1cc/0x58c) from [<c0056a18>] (worker_thread+0x17c/0x464)
kernel: [51945.266601] [<c0056a18>] (worker_thread+0x17c/0x464) from [<c005bce0>] (kthread+0xb4/0xc0)
kernel: [51945.275299] [<c005bce0>] (kthread+0xb4/0xc0) from [<c000e470>] (ret_from_fork+0x14/0x20)
kernel: [51945.283813] ---[ end trace fd1fce56cb4aa3ab ]---
kernel: [51945.288665] EXT4-fs (sda2): ext4_convert_unwritten_extents:4544: inode #16: block 10492: len 7: ext4_ext_map_blocks returned -28
kernel: [51945.300842] EXT4-fs (sda2): failed to convert unwritten extents to written extents -- potential data loss!  (inode 16, offset 42876928, size 126976, error -28)

BEGIN TEST: Ext4 4k block w/data=journal Fri Feb 22 03:30:59 EST 2013
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 068 069 070 074 075 076
 077 079 083 088 089 091 100 105 112 113 117 120 123 124 125 126 127 128 129
 130 131 132 133 135 141 169 184 192 193 198 204 207 208 209 210 211 212 213
 214 215 219 221 223 224 225 226 228 230 231 232 233 234 235 236 237 239 240
 243 245 246 247 248 249 255 256 257 258 263 269 270 271 272 273 274 275 277
 280 285 289 294
Failures: 125 223 274
END TEST: Ext4 4k block w/data=journal Fri Feb 22 06:30:44 EST 2013

Xfstest 224 resulted in this in the kernel log:

kernel: [59876.623382] JBD2: Spotted dirty metadata buffer (dev = sda2, blocknr = 238813). There's a risk of filesystem corruption in case of system crash.


BEGIN TEST: Ext4 4k block w/bigalloc Fri Feb 22 11:55:11 EST 2013
    +_check_generic_filesystem: filesystem on /dev/sda2 is inconsistent (see
077.full)
Ran: 001 002 005 006 007 011 013 014 015 020 053 062 068 069 070 074 075 076
 077 079 083 088 089 091 100 105 112 113 117 120 123 124 125 126 127 128 129
 130 131 132 133 135 141 169 184 192 193 198 204 207 208 209 210 211 212 213
 214 215 219 221 223 224 225 226 228 230 231 232 233 234 235 236 237 239 240
 243 245 246 247 248 249 257 258 263 269 270 271 272 273 274 275 277 280 285
 289 294
Failures: 015 077 125 204 219 233 235 273 274 275
END TEST: Ext4 4k block w/bigalloc Fri Feb 22 13:21:17 EST 2013

There are numerous kernel messages in the syslog triggered by various tests
in addition to these failures, but given that work is in progress to address
some of these I'm going to omit the voluminous details for now.

Also, 015 hung twice and 275 hung once while attempting to get a clean
bigalloc run.  The 015 hang was the same as previously reported for 3.8-rc6.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ