* new kernel warning when running xfstest ext4/271 on 3.12
@ 2013-10-14 2:16 Eric Whitney
2013-10-15 3:51 ` jon ernst
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Eric Whitney @ 2013-10-14 2:16 UTC (permalink / raw)
To: linux-ext4
Since 3.12-rc1, I've noticed a new warning message in my kernel logs when
running ext4 regression tests with xfstests on both my x86-64 (KVM guest) and
ARM (Pandaboard ES) SUTs. (I'm using xfstests-bld to run xfstests.) It
remains visible in 3.12-rc4.
The warning appears when running ext4/271 after mounting the test file system
with the dioread_nolock option.
After running ext4/271, the kernel log contains the following trace repeated
21 times, apparently once for each write performed by dd in the test:
EXT4-fs (vdc): mounted filesystem without journal. Opts: dioread_nolock,noload
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1366 at fs/ext4/page-io.c:205 ext4_put_io_end_defer+0xf5/0x100()
Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer psmouse serio_raw snd soundcore virtio_balloon snd_page_alloc i2c_piix4 mac_hid lp parport floppy
CPU: 1 PID: 1366 Comm: dd Not tainted 3.12.0-rc4-ext4testing+ #1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
0000000000000009 ffff88003fd03d10 ffffffff816e3b66 0000000000000000
ffff88003fd03d48 ffffffff8104eb4c ffff88003d1a1168 ffff88003d209c10
0000000000000000 0000000000001000 ffff88003bb57490 ffff88003fd03d58
Call Trace:
<IRQ> [<ffffffff816e3b66>] dump_stack+0x45/0x56
[<ffffffff8104eb4c>] warn_slowpath_common+0x8c/0xc0
[<ffffffff8104eb9a>] warn_slowpath_null+0x1a/0x20
[<ffffffff81245df5>] ext4_put_io_end_defer+0xf5/0x100
[<ffffffff81245ec6>] ext4_end_bio+0xc6/0xe0
[<ffffffff811d206d>] bio_endio+0x1d/0x30
[<ffffffff8133313a>] blk_update_request+0xba/0x450
[<ffffffff813333e0>] ? blk_update_request+0x360/0x450
[<ffffffff813334f7>] blk_update_bidi_request+0x27/0xa0
[<ffffffff81336720>] __blk_end_bidi_request+0x20/0x50
[<ffffffff8133676f>] __blk_end_request_all+0x1f/0x30
[<ffffffff81480a20>] virtblk_done+0x100/0x260
[<ffffffff81412b11>] vring_interrupt+0x31/0x50
[<ffffffff810a6394>] handle_irq_event_percpu+0x54/0x1f0
[<ffffffff810a6578>] handle_irq_event+0x48/0x70
[<ffffffff810a8de7>] handle_edge_irq+0x77/0x110
[<ffffffff810044de>] handle_irq+0x1e/0x30
[<ffffffff816f70ba>] do_IRQ+0x5a/0xe0
[<ffffffff816ecdaf>] common_interrupt+0x6f/0x6f
<EOI> [<ffffffff810be18e>] ? lock_acquire+0x9e/0x100
[<ffffffff811a76ad>] ? path_init+0x26d/0x4c0
[<ffffffff8107ca94>] lg_local_lock+0x34/0x70
[<ffffffff811a76ad>] ? path_init+0x26d/0x4c0
[<ffffffff811a76ad>] path_init+0x26d/0x4c0
[<ffffffff81370898>] ? __raw_spin_lock_init+0x38/0x70
[<ffffffff811abbb1>] path_openat+0x81/0x660
[<ffffffff81165031>] ? handle_mm_fault+0x2d1/0xaf0
[<ffffffff816f0638>] ? __do_page_fault+0x148/0x570
[<ffffffff811ac4b3>] do_filp_open+0x43/0xa0
[<ffffffff816ec897>] ? _raw_spin_unlock+0x27/0x30
[<ffffffff811b9876>] ? __alloc_fd+0xd6/0x130
[<ffffffff8119a62c>] do_sys_open+0x13c/0x230
[<ffffffff8119a742>] SyS_open+0x22/0x30
[<ffffffff816f5192>] system_call_fastpath+0x16/0x1b
---[ end trace bd3f4c22c85fc732 ]---
The test itself concludes successfully as written, though it's worth noting
the test does not check the integrity of the data written.
The same warning can be triggered by the following simple sequence of
commands, extracted from ext4/271:
mkfs.ext4 /dev/vdc
mount -o dioread_nolock,noload /dev/vdc /vdc
touch /vdc/file
chattr +S /vdc/file
dd if=/dev/zero of=/vdc/file bs=4k count=1
(FWIW, if you omit the touch and chattr commands, the warning won't be
triggered unless a second instance of the dd command is issued.)
The warning bisects cleanly to this patch:
7b7a8665ed direct-io: Implement generic deferred AIO completions
Apparently, !io_end->handle is unexpectedly true in this test case. A
WARN_ON for that condition was newly added in the patch.
It's not yet clear to me how serious this warning is, but the new message is
at least a minor regression.
Thanks,
Eric
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: new kernel warning when running xfstest ext4/271 on 3.12
2013-10-14 2:16 new kernel warning when running xfstest ext4/271 on 3.12 Eric Whitney
@ 2013-10-15 3:51 ` jon ernst
2013-10-15 13:12 ` Jan Kara
2013-10-15 13:26 ` Jan Kara
2 siblings, 0 replies; 4+ messages in thread
From: jon ernst @ 2013-10-15 3:51 UTC (permalink / raw)
To: Eric Whitney; +Cc: linux-ext4@vger.kernel.org List
On Sun, Oct 13, 2013 at 10:16 PM, Eric Whitney <enwlinux@gmail.com> wrote:
>
> Since 3.12-rc1, I've noticed a new warning message in my kernel logs when
> running ext4 regression tests with xfstests on both my x86-64 (KVM guest) and
> ARM (Pandaboard ES) SUTs. (I'm using xfstests-bld to run xfstests.) It
> remains visible in 3.12-rc4.
>
> The warning appears when running ext4/271 after mounting the test file system
> with the dioread_nolock option.
>
> After running ext4/271, the kernel log contains the following trace repeated
> 21 times, apparently once for each write performed by dd in the test:
>
> EXT4-fs (vdc): mounted filesystem without journal. Opts: dioread_nolock,noload
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 1366 at fs/ext4/page-io.c:205 ext4_put_io_end_defer+0xf5/0x100()
> Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer psmouse serio_raw snd soundcore virtio_balloon snd_page_alloc i2c_piix4 mac_hid lp parport floppy
> CPU: 1 PID: 1366 Comm: dd Not tainted 3.12.0-rc4-ext4testing+ #1
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> 0000000000000009 ffff88003fd03d10 ffffffff816e3b66 0000000000000000
> ffff88003fd03d48 ffffffff8104eb4c ffff88003d1a1168 ffff88003d209c10
> 0000000000000000 0000000000001000 ffff88003bb57490 ffff88003fd03d58
> Call Trace:
> <IRQ> [<ffffffff816e3b66>] dump_stack+0x45/0x56
> [<ffffffff8104eb4c>] warn_slowpath_common+0x8c/0xc0
> [<ffffffff8104eb9a>] warn_slowpath_null+0x1a/0x20
> [<ffffffff81245df5>] ext4_put_io_end_defer+0xf5/0x100
> [<ffffffff81245ec6>] ext4_end_bio+0xc6/0xe0
> [<ffffffff811d206d>] bio_endio+0x1d/0x30
> [<ffffffff8133313a>] blk_update_request+0xba/0x450
> [<ffffffff813333e0>] ? blk_update_request+0x360/0x450
> [<ffffffff813334f7>] blk_update_bidi_request+0x27/0xa0
> [<ffffffff81336720>] __blk_end_bidi_request+0x20/0x50
> [<ffffffff8133676f>] __blk_end_request_all+0x1f/0x30
> [<ffffffff81480a20>] virtblk_done+0x100/0x260
> [<ffffffff81412b11>] vring_interrupt+0x31/0x50
> [<ffffffff810a6394>] handle_irq_event_percpu+0x54/0x1f0
> [<ffffffff810a6578>] handle_irq_event+0x48/0x70
> [<ffffffff810a8de7>] handle_edge_irq+0x77/0x110
> [<ffffffff810044de>] handle_irq+0x1e/0x30
> [<ffffffff816f70ba>] do_IRQ+0x5a/0xe0
> [<ffffffff816ecdaf>] common_interrupt+0x6f/0x6f
> <EOI> [<ffffffff810be18e>] ? lock_acquire+0x9e/0x100
> [<ffffffff811a76ad>] ? path_init+0x26d/0x4c0
> [<ffffffff8107ca94>] lg_local_lock+0x34/0x70
> [<ffffffff811a76ad>] ? path_init+0x26d/0x4c0
> [<ffffffff811a76ad>] path_init+0x26d/0x4c0
> [<ffffffff81370898>] ? __raw_spin_lock_init+0x38/0x70
> [<ffffffff811abbb1>] path_openat+0x81/0x660
> [<ffffffff81165031>] ? handle_mm_fault+0x2d1/0xaf0
> [<ffffffff816f0638>] ? __do_page_fault+0x148/0x570
> [<ffffffff811ac4b3>] do_filp_open+0x43/0xa0
> [<ffffffff816ec897>] ? _raw_spin_unlock+0x27/0x30
> [<ffffffff811b9876>] ? __alloc_fd+0xd6/0x130
> [<ffffffff8119a62c>] do_sys_open+0x13c/0x230
> [<ffffffff8119a742>] SyS_open+0x22/0x30
> [<ffffffff816f5192>] system_call_fastpath+0x16/0x1b
> ---[ end trace bd3f4c22c85fc732 ]---
>
> The test itself concludes successfully as written, though it's worth noting
> the test does not check the integrity of the data written.
>
> The same warning can be triggered by the following simple sequence of
> commands, extracted from ext4/271:
>
> mkfs.ext4 /dev/vdc
> mount -o dioread_nolock,noload /dev/vdc /vdc
> touch /vdc/file
> chattr +S /vdc/file
> dd if=/dev/zero of=/vdc/file bs=4k count=1
>
> (FWIW, if you omit the touch and chattr commands, the warning won't be
> triggered unless a second instance of the dd command is issued.)
>
> The warning bisects cleanly to this patch:
> 7b7a8665ed direct-io: Implement generic deferred AIO completions
>
> Apparently, !io_end->handle is unexpectedly true in this test case. A
> WARN_ON for that condition was newly added in the patch.
>
> It's not yet clear to me how serious this warning is, but the new message is
> at least a minor regression.
>
> Thanks,
> Eric
>
I have tested it too. Got same result as yours. I also put some
printks to see runtime values.
It turned out io_end->handle is always 0 when I ran your test case.
And, flag is EXT4_IO_END_UNWRITTEN just before WARNNING been triggered.
and io_end->size is always 4096 on my machine.
Below is my dump. Hope it provides a little bit more information.
[ 313.464892] ext4 io_end->handle is 0,
[ 313.464900] is EXT4_IO_END_UNWRITTEN
[ 313.464901] io_end->size = 4096.
[ 313.464902] ------------[ cut here ]------------
[ 313.464907] WARNING: CPU: 0 PID: 0 at fs/ext4/page-io.c:205
ext4_put_io_end_defer+0xef/0x110()
[ 313.464908] Modules linked in: kvm_intel kvm bnep rfcomm bluetooth
parport_pc ppdev binfmt_misc snd_hda_codec_hdmi snd_hda_codec_conexant
snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi i915
snd_rawmidi snd_seq_midi_event joydev snd_seq drm_kms_helper drm
snd_timer snd_seq_device psmouse snd soundcore serio_raw lpc_ich
dcdbas snd_page_alloc i2c_algo_bit video mac_hid coretemp lp parport
hid_generic usbhid r8169 hid mii
[ 313.464941] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0-rc4+ #3
[ 313.464942] Hardware name: *** , BIOS A04 11/21/2011
[ 313.464943] 00000000000000cd ffff8801bfa03c10 ffffffff816903c7
0000000000000e4b
[ 313.464945] 0000000000000000 ffff8801bfa03c50 ffffffff8104e34c
ffff8801bfa03c70
[ 313.464947] ffff8800302a31f8 ffff8801ada1cc20 0000000000000000
ffff88008da85180
[ 313.464949] Call Trace:
[ 313.464950] <IRQ> [<ffffffff816903c7>] dump_stack+0x46/0x58
[ 313.464957] [<ffffffff8104e34c>] warn_slowpath_common+0x8c/0xc0
[ 313.464959] [<ffffffff8104e39a>] warn_slowpath_null+0x1a/0x20
[ 313.464961] [<ffffffff8122a2ef>] ext4_put_io_end_defer+0xef/0x110
[ 313.464963] [<ffffffff81494bc9>] ? ata_scsi_qc_complete+0x69/0x460
[ 313.464965] [<ffffffff8122a402>] ext4_end_bio+0xf2/0x100
[ 313.464967] [<ffffffff811baebd>] bio_endio+0x1d/0x40
[ 313.464970] [<ffffffff81307c98>] blk_update_request+0xb8/0x3f0
[ 313.464973] [<ffffffff8148e05d>] ? ata_qc_complete+0x9d/0x230
[ 313.464975] [<ffffffff81308001>] blk_update_bidi_request+0x31/0x90
[ 313.464977] [<ffffffff8130870c>] blk_end_bidi_request+0x2c/0x80
[ 313.464979] [<ffffffff813087a0>] blk_end_request+0x10/0x20
[ 313.464982] [<ffffffff81465f5f>] scsi_io_completion+0xaf/0x710
[ 313.464984] [<ffffffff814a0a50>] ? ata_sff_softreset+0x190/0x190
[ 313.464987] [<ffffffff8145c7e1>] scsi_finish_command+0xc1/0x120
[ 313.464988] [<ffffffff81465dbe>] scsi_softirq_done+0x13e/0x150
[ 313.464990] [<ffffffff8130f0a3>] blk_done_softirq+0x73/0x90
[ 313.464993] [<ffffffff81052f90>] __do_softirq+0xd0/0x270
[ 313.464996] [<ffffffff816a0a5c>] call_softirq+0x1c/0x30
[ 313.464998] [<ffffffff810045a5>] do_softirq+0x55/0x90
[ 313.465000] [<ffffffff81053276>] irq_exit+0x86/0xb0
[ 313.465002] [<ffffffff816a10e3>] do_IRQ+0x63/0xe0
[ 313.465004] [<ffffffff8169736a>] common_interrupt+0x6a/0x6a
[ 313.465005] <EOI> [<ffffffff8107480f>] ?
__hrtimer_start_range_ns+0x18f/0x490
[ 313.465011] [<ffffffff8155313b>] ? cpuidle_enter_state+0x5b/0xe0
[ 313.465012] [<ffffffff81553137>] ? cpuidle_enter_state+0x57/0xe0
[ 313.465014] [<ffffffff81553280>] cpuidle_idle_call+0xc0/0x220
[ 313.465017] [<ffffffff8100b7fe>] arch_cpu_idle+0xe/0x30
[ 313.465019] [<ffffffff810a0ace>] cpu_startup_entry+0xce/0x290
[ 313.465022] [<ffffffff81681f07>] rest_init+0x77/0x80
[ 313.465025] [<ffffffff81d04e64>] start_kernel+0x3d3/0x3e0
[ 313.465027] [<ffffffff81d04891>] ? repair_env_string+0x5a/0x5a
[ 313.465029] [<ffffffff81d045a8>] x86_64_start_reservations+0x2a/0x2c
[ 313.465030] [<ffffffff81d04696>] x86_64_start_kernel+0xec/0xf3
[ 313.465031] ---[ end trace da7f582e4c5a7b8c ]--
> --
> 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] 4+ messages in thread
* Re: new kernel warning when running xfstest ext4/271 on 3.12
2013-10-14 2:16 new kernel warning when running xfstest ext4/271 on 3.12 Eric Whitney
2013-10-15 3:51 ` jon ernst
@ 2013-10-15 13:12 ` Jan Kara
2013-10-15 13:26 ` Jan Kara
2 siblings, 0 replies; 4+ messages in thread
From: Jan Kara @ 2013-10-15 13:12 UTC (permalink / raw)
To: Eric Whitney; +Cc: linux-ext4
On Sun 13-10-13 22:16:06, Eric Whitney wrote:
> Since 3.12-rc1, I've noticed a new warning message in my kernel logs when
> running ext4 regression tests with xfstests on both my x86-64 (KVM guest) and
> ARM (Pandaboard ES) SUTs. (I'm using xfstests-bld to run xfstests.) It
> remains visible in 3.12-rc4.
>
> The warning appears when running ext4/271 after mounting the test file system
> with the dioread_nolock option.
>
> After running ext4/271, the kernel log contains the following trace repeated
> 21 times, apparently once for each write performed by dd in the test:
>
> EXT4-fs (vdc): mounted filesystem without journal. Opts: dioread_nolock,noload
Ah, OK. Unusual combination of mount options about which I didn't think
when writing the assertion :) The warning is false positive - in nojournal
mode it doesn't make sense to ask for a reserved handle. I'll send a fix to
silence the warning. Thanks for report!
Honza
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 1366 at fs/ext4/page-io.c:205 ext4_put_io_end_defer+0xf5/0x100()
> Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer psmouse serio_raw snd soundcore virtio_balloon snd_page_alloc i2c_piix4 mac_hid lp parport floppy
> CPU: 1 PID: 1366 Comm: dd Not tainted 3.12.0-rc4-ext4testing+ #1
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> 0000000000000009 ffff88003fd03d10 ffffffff816e3b66 0000000000000000
> ffff88003fd03d48 ffffffff8104eb4c ffff88003d1a1168 ffff88003d209c10
> 0000000000000000 0000000000001000 ffff88003bb57490 ffff88003fd03d58
> Call Trace:
> <IRQ> [<ffffffff816e3b66>] dump_stack+0x45/0x56
> [<ffffffff8104eb4c>] warn_slowpath_common+0x8c/0xc0
> [<ffffffff8104eb9a>] warn_slowpath_null+0x1a/0x20
> [<ffffffff81245df5>] ext4_put_io_end_defer+0xf5/0x100
> [<ffffffff81245ec6>] ext4_end_bio+0xc6/0xe0
> [<ffffffff811d206d>] bio_endio+0x1d/0x30
> [<ffffffff8133313a>] blk_update_request+0xba/0x450
> [<ffffffff813333e0>] ? blk_update_request+0x360/0x450
> [<ffffffff813334f7>] blk_update_bidi_request+0x27/0xa0
> [<ffffffff81336720>] __blk_end_bidi_request+0x20/0x50
> [<ffffffff8133676f>] __blk_end_request_all+0x1f/0x30
> [<ffffffff81480a20>] virtblk_done+0x100/0x260
> [<ffffffff81412b11>] vring_interrupt+0x31/0x50
> [<ffffffff810a6394>] handle_irq_event_percpu+0x54/0x1f0
> [<ffffffff810a6578>] handle_irq_event+0x48/0x70
> [<ffffffff810a8de7>] handle_edge_irq+0x77/0x110
> [<ffffffff810044de>] handle_irq+0x1e/0x30
> [<ffffffff816f70ba>] do_IRQ+0x5a/0xe0
> [<ffffffff816ecdaf>] common_interrupt+0x6f/0x6f
> <EOI> [<ffffffff810be18e>] ? lock_acquire+0x9e/0x100
> [<ffffffff811a76ad>] ? path_init+0x26d/0x4c0
> [<ffffffff8107ca94>] lg_local_lock+0x34/0x70
> [<ffffffff811a76ad>] ? path_init+0x26d/0x4c0
> [<ffffffff811a76ad>] path_init+0x26d/0x4c0
> [<ffffffff81370898>] ? __raw_spin_lock_init+0x38/0x70
> [<ffffffff811abbb1>] path_openat+0x81/0x660
> [<ffffffff81165031>] ? handle_mm_fault+0x2d1/0xaf0
> [<ffffffff816f0638>] ? __do_page_fault+0x148/0x570
> [<ffffffff811ac4b3>] do_filp_open+0x43/0xa0
> [<ffffffff816ec897>] ? _raw_spin_unlock+0x27/0x30
> [<ffffffff811b9876>] ? __alloc_fd+0xd6/0x130
> [<ffffffff8119a62c>] do_sys_open+0x13c/0x230
> [<ffffffff8119a742>] SyS_open+0x22/0x30
> [<ffffffff816f5192>] system_call_fastpath+0x16/0x1b
> ---[ end trace bd3f4c22c85fc732 ]---
>
> The test itself concludes successfully as written, though it's worth noting
> the test does not check the integrity of the data written.
>
> The same warning can be triggered by the following simple sequence of
> commands, extracted from ext4/271:
>
> mkfs.ext4 /dev/vdc
> mount -o dioread_nolock,noload /dev/vdc /vdc
> touch /vdc/file
> chattr +S /vdc/file
> dd if=/dev/zero of=/vdc/file bs=4k count=1
>
> (FWIW, if you omit the touch and chattr commands, the warning won't be
> triggered unless a second instance of the dd command is issued.)
>
> The warning bisects cleanly to this patch:
> 7b7a8665ed direct-io: Implement generic deferred AIO completions
>
> Apparently, !io_end->handle is unexpectedly true in this test case. A
> WARN_ON for that condition was newly added in the patch.
>
> It's not yet clear to me how serious this warning is, but the new message is
> at least a minor regression.
>
> Thanks,
> Eric
>
> --
> 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
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: new kernel warning when running xfstest ext4/271 on 3.12
2013-10-14 2:16 new kernel warning when running xfstest ext4/271 on 3.12 Eric Whitney
2013-10-15 3:51 ` jon ernst
2013-10-15 13:12 ` Jan Kara
@ 2013-10-15 13:26 ` Jan Kara
2 siblings, 0 replies; 4+ messages in thread
From: Jan Kara @ 2013-10-15 13:26 UTC (permalink / raw)
To: Eric Whitney; +Cc: linux-ext4
[-- Attachment #1: Type: text/plain, Size: 4323 bytes --]
On Sun 13-10-13 22:16:06, Eric Whitney wrote:
> Since 3.12-rc1, I've noticed a new warning message in my kernel logs when
> running ext4 regression tests with xfstests on both my x86-64 (KVM guest) and
> ARM (Pandaboard ES) SUTs. (I'm using xfstests-bld to run xfstests.) It
> remains visible in 3.12-rc4.
>
> The warning appears when running ext4/271 after mounting the test file system
> with the dioread_nolock option.
>
> After running ext4/271, the kernel log contains the following trace repeated
> 21 times, apparently once for each write performed by dd in the test:
Attached patch should fix this.
Honza
>
> EXT4-fs (vdc): mounted filesystem without journal. Opts: dioread_nolock,noload
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 1366 at fs/ext4/page-io.c:205 ext4_put_io_end_defer+0xf5/0x100()
> Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer psmouse serio_raw snd soundcore virtio_balloon snd_page_alloc i2c_piix4 mac_hid lp parport floppy
> CPU: 1 PID: 1366 Comm: dd Not tainted 3.12.0-rc4-ext4testing+ #1
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> 0000000000000009 ffff88003fd03d10 ffffffff816e3b66 0000000000000000
> ffff88003fd03d48 ffffffff8104eb4c ffff88003d1a1168 ffff88003d209c10
> 0000000000000000 0000000000001000 ffff88003bb57490 ffff88003fd03d58
> Call Trace:
> <IRQ> [<ffffffff816e3b66>] dump_stack+0x45/0x56
> [<ffffffff8104eb4c>] warn_slowpath_common+0x8c/0xc0
> [<ffffffff8104eb9a>] warn_slowpath_null+0x1a/0x20
> [<ffffffff81245df5>] ext4_put_io_end_defer+0xf5/0x100
> [<ffffffff81245ec6>] ext4_end_bio+0xc6/0xe0
> [<ffffffff811d206d>] bio_endio+0x1d/0x30
> [<ffffffff8133313a>] blk_update_request+0xba/0x450
> [<ffffffff813333e0>] ? blk_update_request+0x360/0x450
> [<ffffffff813334f7>] blk_update_bidi_request+0x27/0xa0
> [<ffffffff81336720>] __blk_end_bidi_request+0x20/0x50
> [<ffffffff8133676f>] __blk_end_request_all+0x1f/0x30
> [<ffffffff81480a20>] virtblk_done+0x100/0x260
> [<ffffffff81412b11>] vring_interrupt+0x31/0x50
> [<ffffffff810a6394>] handle_irq_event_percpu+0x54/0x1f0
> [<ffffffff810a6578>] handle_irq_event+0x48/0x70
> [<ffffffff810a8de7>] handle_edge_irq+0x77/0x110
> [<ffffffff810044de>] handle_irq+0x1e/0x30
> [<ffffffff816f70ba>] do_IRQ+0x5a/0xe0
> [<ffffffff816ecdaf>] common_interrupt+0x6f/0x6f
> <EOI> [<ffffffff810be18e>] ? lock_acquire+0x9e/0x100
> [<ffffffff811a76ad>] ? path_init+0x26d/0x4c0
> [<ffffffff8107ca94>] lg_local_lock+0x34/0x70
> [<ffffffff811a76ad>] ? path_init+0x26d/0x4c0
> [<ffffffff811a76ad>] path_init+0x26d/0x4c0
> [<ffffffff81370898>] ? __raw_spin_lock_init+0x38/0x70
> [<ffffffff811abbb1>] path_openat+0x81/0x660
> [<ffffffff81165031>] ? handle_mm_fault+0x2d1/0xaf0
> [<ffffffff816f0638>] ? __do_page_fault+0x148/0x570
> [<ffffffff811ac4b3>] do_filp_open+0x43/0xa0
> [<ffffffff816ec897>] ? _raw_spin_unlock+0x27/0x30
> [<ffffffff811b9876>] ? __alloc_fd+0xd6/0x130
> [<ffffffff8119a62c>] do_sys_open+0x13c/0x230
> [<ffffffff8119a742>] SyS_open+0x22/0x30
> [<ffffffff816f5192>] system_call_fastpath+0x16/0x1b
> ---[ end trace bd3f4c22c85fc732 ]---
>
> The test itself concludes successfully as written, though it's worth noting
> the test does not check the integrity of the data written.
>
> The same warning can be triggered by the following simple sequence of
> commands, extracted from ext4/271:
>
> mkfs.ext4 /dev/vdc
> mount -o dioread_nolock,noload /dev/vdc /vdc
> touch /vdc/file
> chattr +S /vdc/file
> dd if=/dev/zero of=/vdc/file bs=4k count=1
>
> (FWIW, if you omit the touch and chattr commands, the warning won't be
> triggered unless a second instance of the dd command is issued.)
>
> The warning bisects cleanly to this patch:
> 7b7a8665ed direct-io: Implement generic deferred AIO completions
>
> Apparently, !io_end->handle is unexpectedly true in this test case. A
> WARN_ON for that condition was newly added in the patch.
>
> It's not yet clear to me how serious this warning is, but the new message is
> at least a minor regression.
>
> Thanks,
> Eric
>
> --
> 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
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
[-- Attachment #2: 0001-ext4-Fix-assertion-in-ext4_add_complete_io.patch --]
[-- Type: text/x-patch, Size: 1507 bytes --]
>From 3575f7ab985e3f8ddbddf88e72b93ece20a113e6 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Tue, 15 Oct 2013 15:17:48 +0200
Subject: [PATCH] ext4: Fix assertion in ext4_add_complete_io()
It doesn't make sense to require io_end->handle when we are in nojournal
mode. So update the assertion accordingly to avoid false warnings from
ext4_add_complete_io().
Reported-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext4/page-io.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
index d7d0c7b46ed4..d488f80ee32d 100644
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -197,14 +197,15 @@ static void dump_completed_IO(struct inode *inode, struct list_head *head)
static void ext4_add_complete_io(ext4_io_end_t *io_end)
{
struct ext4_inode_info *ei = EXT4_I(io_end->inode);
+ struct ext4_sb_info *sbi = EXT4_SB(io_end->inode->i_sb);
struct workqueue_struct *wq;
unsigned long flags;
/* Only reserved conversions from writeback should enter here */
WARN_ON(!(io_end->flag & EXT4_IO_END_UNWRITTEN));
- WARN_ON(!io_end->handle);
+ WARN_ON(!io_end->handle && sbi->s_journal);
spin_lock_irqsave(&ei->i_completed_io_lock, flags);
- wq = EXT4_SB(io_end->inode->i_sb)->rsv_conversion_wq;
+ wq = sbi->rsv_conversion_wq;
if (list_empty(&ei->i_rsv_conversion_list))
queue_work(wq, &ei->i_rsv_conversion_work);
list_add_tail(&io_end->list, &ei->i_rsv_conversion_list);
--
1.8.1.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-10-15 13:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-14 2:16 new kernel warning when running xfstest ext4/271 on 3.12 Eric Whitney
2013-10-15 3:51 ` jon ernst
2013-10-15 13:12 ` Jan Kara
2013-10-15 13:26 ` Jan Kara
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).