Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1264824 > unrolled thread

WARNING: CPU: 0 PID: 1 at fs/block_dev.c:58 __blkdev_put+0x16f/0x1b0()

Started byRichard Weinberger <richard@nod.at>
First post2015-11-07 13:10 +0100
Last post2015-11-09 17:20 +0100
Articles 3 — 3 participants

Back to article view | Back to linux.kernel

Contents

  WARNING: CPU: 0 PID: 1 at fs/block_dev.c:58  __blkdev_put+0x16f/0x1b0() Richard Weinberger <richard@nod.at> - 2015-11-07 13:10 +0100
    Re: WARNING: CPU: 0 PID: 1 at fs/block_dev.c:58  __blkdev_put+0x16f/0x1b0() Jan Kara <jack@suse.cz> - 2015-11-09 10:30 +0100
      Re: WARNING: CPU: 0 PID: 1 at fs/block_dev.c:58 __blkdev_put+0x16f/0x1b0() Jeff Moyer <jmoyer@redhat.com> - 2015-11-09 17:20 +0100

#1264824 — WARNING: CPU: 0 PID: 1 at fs/block_dev.c:58 __blkdev_put+0x16f/0x1b0()

FromRichard Weinberger <richard@nod.at>
Date2015-11-07 13:10 +0100
SubjectWARNING: CPU: 0 PID: 1 at fs/block_dev.c:58 __blkdev_put+0x16f/0x1b0()
Message-ID<qsatH-25S-9@gated-at.bofh.it>
Hi!

While playing with the Linux kernel library I run into this warning.
Root cause of the warning is that the backing file on the host
side is locked an therefore all IO on it results into -EIO.

The question is whether ext4/jbd2 should abort earlier or not.
The WARN_ON_ONCE in bdev_write_inode() triggers as jbd2's do_one_pass()
sets up a dirty buffer_head and fails later.
Then ext4 gives up, calls blkdev_put() and we reach bdev_write_inode()
with a dirty ->bd_inode.

What do you think?

[    0.128000] blk_update_request: I/O error, dev vda, sector 0
[    0.128000] Buffer I/O error on dev vda, logical block 0, lost async page write
[    0.128000] blk_update_request: I/O error, dev vda, sector 8
[    0.128000] Buffer I/O error on dev vda, logical block 1, lost async page write
[    0.128000] blk_update_request: I/O error, dev vda, sector 528
[    0.128000] Buffer I/O error on dev vda, logical block 66, lost async page write
[    0.128000] blk_update_request: I/O error, dev vda, sector 1824
[    0.128000] Buffer I/O error on dev vda, logical block 228, lost async page write
[    0.128000] blk_update_request: I/O error, dev vda, sector 1864
[    0.128000] Buffer I/O error on dev vda, logical block 233, lost async page write
[    0.128000] blk_update_request: I/O error, dev vda, sector 41840
[    0.128000] Buffer I/O error on dev vda, logical block 5230, lost async page write
[    0.128000] blk_update_request: I/O error, dev vda, sector 262672
[    0.128000] Buffer I/O error on dev vda, logical block 32834, lost async page write
[    0.128000] blk_update_request: I/O error, dev vda, sector 262680
[    0.128000] Buffer I/O error on dev vda, logical block 32835, lost async page write
[    0.128000] blk_update_request: I/O error, dev vda, sector 262752
[    0.128000] Buffer I/O error on dev vda, logical block 32844, lost async page write
[    0.128000] blk_update_request: I/O error, dev vda, sector 262792
[    0.128000] Buffer I/O error on dev vda, logical block 32849, lost async page write
[    0.132000] JBD2: recovery failed
[    0.132000] EXT4-fs (vda): error loading journal
[    0.132000] ------------[ cut here ]------------
[    0.132000] WARNING: CPU: 0 PID: 1 at fs/block_dev.c:58 __blkdev_put+0x16f/0x1b0()
[    0.132000] Call Trace:
[    0.132000] 00007fd99262db68:  [<0040673d>] warn_slowpath_common+0x7d/0xb0
[    0.132000] 00007fd99262dba8:  [<004068d5>] warn_slowpath_null+0x15/0x20
[    0.132000] 00007fd99262dbb8:  [<0048efbf>] __blkdev_put+0x16f/0x1b0
[    0.132000] 00007fd99262dbf8:  [<0048fcd2>] blkdev_put+0x92/0x110
[    0.132000] 00007fd99262dc28:  [<00462faf>] kill_block_super+0x3f/0x70
[    0.132000] 00007fd99262dc48:  [<00461bf2>] deactivate_locked_super+0x52/0xb0
[    0.132000] 00007fd99262dc78:  [<00462f51>] mount_bdev+0x1b1/0x1d0
[    0.132000] 00007fd99262dc80:  [<004c5c40>] ext4_fill_super+0x0/0x32f0
[    0.132000] 00007fd99262dce8:  [<004c16f0>] ext4_mount+0x10/0x20
[    0.132000] 00007fd99262dcf8:  [<00463164>] mount_fs+0x14/0xc0
[    0.132000] 00007fd99262dd28:  [<0047a38e>] vfs_kern_mount+0x5e/0x120
[    0.132000] 00007fd99262dd78:  [<0047baa8>] do_mount+0x208/0xd90
[    0.132000] 00007fd99262dd88:  [<0045d7db>] __kmalloc_track_caller+0x18b/0x1c0
[    0.132000] 00007fd99262dd98:  [<00450618>] strndup_user+0x48/0x60
[    0.132000] 00007fd99262de08:  [<00450618>] strndup_user+0x48/0x60
[    0.132000] 00007fd99262de48:  [<0047c99a>] SyS_mount+0x6a/0xb0
[    0.132000] 00007fd99262de98:  [<00403b89>] run_syscalls+0xd9/0x1c0
[    0.132000] 00007fd99262deb0:  [<00425970>] autoremove_wake_function+0x0/0x40
[    0.132000] 00007fd99262dec8:  [<005535f0>] kernel_init+0x0/0xf0
[    0.132000] 00007fd99262dee8:  [<005535f0>] kernel_init+0x0/0xf0
[    0.132000] 00007fd99262df08:  [<00402f2d>] run_init_process+0x1d/0x40
[    0.132000] 00007fd99262df18:  [<00553626>] kernel_init+0x36/0xf0
[    0.132000] 00007fd99262df28:  [<00403158>] thread_bootstrap+0x48/0x50
[    0.132000]
[    0.132000] ---[ end trace 0b886a9a044a4995 ]---

Thanks,
//richard
--
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/

[toc] | [next] | [standalone]

#1265473

FromJan Kara <jack@suse.cz>
Date2015-11-09 10:30 +0100
Message-ID<qsQVX-4xo-3@gated-at.bofh.it>
In reply to#1264824
  Hi!

On Sat 07-11-15 13:07:30, Richard Weinberger wrote:
> While playing with the Linux kernel library I run into this warning.
> Root cause of the warning is that the backing file on the host
> side is locked an therefore all IO on it results into -EIO.
> 
> The question is whether ext4/jbd2 should abort earlier or not.
> The WARN_ON_ONCE in bdev_write_inode() triggers as jbd2's do_one_pass()
> sets up a dirty buffer_head and fails later.
> Then ext4 gives up, calls blkdev_put() and we reach bdev_write_inode()
> with a dirty ->bd_inode.
> 
> What do you think?

So I think the right question is what we should do when we cannot writeback
dirty data. Currently we WARN_ON in some places (bdev_write_inode() is one
of them) and print errors in others. Although loosing data is nasty, people
seem to remove devices or do similar stuff too often for WARN_ON to be really
an adequate answer... So I think we should just print error message and go
on without spewing stack traces. Thoughts?

								Honza

> [    0.128000] blk_update_request: I/O error, dev vda, sector 0
> [    0.128000] Buffer I/O error on dev vda, logical block 0, lost async page write
> [    0.128000] blk_update_request: I/O error, dev vda, sector 8
> [    0.128000] Buffer I/O error on dev vda, logical block 1, lost async page write
> [    0.128000] blk_update_request: I/O error, dev vda, sector 528
> [    0.128000] Buffer I/O error on dev vda, logical block 66, lost async page write
> [    0.128000] blk_update_request: I/O error, dev vda, sector 1824
> [    0.128000] Buffer I/O error on dev vda, logical block 228, lost async page write
> [    0.128000] blk_update_request: I/O error, dev vda, sector 1864
> [    0.128000] Buffer I/O error on dev vda, logical block 233, lost async page write
> [    0.128000] blk_update_request: I/O error, dev vda, sector 41840
> [    0.128000] Buffer I/O error on dev vda, logical block 5230, lost async page write
> [    0.128000] blk_update_request: I/O error, dev vda, sector 262672
> [    0.128000] Buffer I/O error on dev vda, logical block 32834, lost async page write
> [    0.128000] blk_update_request: I/O error, dev vda, sector 262680
> [    0.128000] Buffer I/O error on dev vda, logical block 32835, lost async page write
> [    0.128000] blk_update_request: I/O error, dev vda, sector 262752
> [    0.128000] Buffer I/O error on dev vda, logical block 32844, lost async page write
> [    0.128000] blk_update_request: I/O error, dev vda, sector 262792
> [    0.128000] Buffer I/O error on dev vda, logical block 32849, lost async page write
> [    0.132000] JBD2: recovery failed
> [    0.132000] EXT4-fs (vda): error loading journal
> [    0.132000] ------------[ cut here ]------------
> [    0.132000] WARNING: CPU: 0 PID: 1 at fs/block_dev.c:58 __blkdev_put+0x16f/0x1b0()
> [    0.132000] Call Trace:
> [    0.132000] 00007fd99262db68:  [<0040673d>] warn_slowpath_common+0x7d/0xb0
> [    0.132000] 00007fd99262dba8:  [<004068d5>] warn_slowpath_null+0x15/0x20
> [    0.132000] 00007fd99262dbb8:  [<0048efbf>] __blkdev_put+0x16f/0x1b0
> [    0.132000] 00007fd99262dbf8:  [<0048fcd2>] blkdev_put+0x92/0x110
> [    0.132000] 00007fd99262dc28:  [<00462faf>] kill_block_super+0x3f/0x70
> [    0.132000] 00007fd99262dc48:  [<00461bf2>] deactivate_locked_super+0x52/0xb0
> [    0.132000] 00007fd99262dc78:  [<00462f51>] mount_bdev+0x1b1/0x1d0
> [    0.132000] 00007fd99262dc80:  [<004c5c40>] ext4_fill_super+0x0/0x32f0
> [    0.132000] 00007fd99262dce8:  [<004c16f0>] ext4_mount+0x10/0x20
> [    0.132000] 00007fd99262dcf8:  [<00463164>] mount_fs+0x14/0xc0
> [    0.132000] 00007fd99262dd28:  [<0047a38e>] vfs_kern_mount+0x5e/0x120
> [    0.132000] 00007fd99262dd78:  [<0047baa8>] do_mount+0x208/0xd90
> [    0.132000] 00007fd99262dd88:  [<0045d7db>] __kmalloc_track_caller+0x18b/0x1c0
> [    0.132000] 00007fd99262dd98:  [<00450618>] strndup_user+0x48/0x60
> [    0.132000] 00007fd99262de08:  [<00450618>] strndup_user+0x48/0x60
> [    0.132000] 00007fd99262de48:  [<0047c99a>] SyS_mount+0x6a/0xb0
> [    0.132000] 00007fd99262de98:  [<00403b89>] run_syscalls+0xd9/0x1c0
> [    0.132000] 00007fd99262deb0:  [<00425970>] autoremove_wake_function+0x0/0x40
> [    0.132000] 00007fd99262dec8:  [<005535f0>] kernel_init+0x0/0xf0
> [    0.132000] 00007fd99262dee8:  [<005535f0>] kernel_init+0x0/0xf0
> [    0.132000] 00007fd99262df08:  [<00402f2d>] run_init_process+0x1d/0x40
> [    0.132000] 00007fd99262df18:  [<00553626>] kernel_init+0x36/0xf0
> [    0.132000] 00007fd99262df28:  [<00403158>] thread_bootstrap+0x48/0x50
> [    0.132000]
> [    0.132000] ---[ end trace 0b886a9a044a4995 ]---
> 
> Thanks,
> //richard
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
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/

[toc] | [prev] | [next] | [standalone]

#1265785 — Re: WARNING: CPU: 0 PID: 1 at fs/block_dev.c:58 __blkdev_put+0x16f/0x1b0()

FromJeff Moyer <jmoyer@redhat.com>
Date2015-11-09 17:20 +0100
SubjectRe: WARNING: CPU: 0 PID: 1 at fs/block_dev.c:58 __blkdev_put+0x16f/0x1b0()
Message-ID<qsXkJ-i7-1@gated-at.bofh.it>
In reply to#1265473
Jan Kara <jack@suse.cz> writes:

>   Hi!
>
> On Sat 07-11-15 13:07:30, Richard Weinberger wrote:
>> While playing with the Linux kernel library I run into this warning.
>> Root cause of the warning is that the backing file on the host
>> side is locked an therefore all IO on it results into -EIO.
>> 
>> The question is whether ext4/jbd2 should abort earlier or not.
>> The WARN_ON_ONCE in bdev_write_inode() triggers as jbd2's do_one_pass()
>> sets up a dirty buffer_head and fails later.
>> Then ext4 gives up, calls blkdev_put() and we reach bdev_write_inode()
>> with a dirty ->bd_inode.
>> 
>> What do you think?
>
> So I think the right question is what we should do when we cannot writeback
> dirty data. Currently we WARN_ON in some places (bdev_write_inode() is one
> of them) and print errors in others. Although loosing data is nasty, people
> seem to remove devices or do similar stuff too often for WARN_ON to be really
> an adequate answer... So I think we should just print error message and go
> on without spewing stack traces. Thoughts?

There's a patch from Vivek to do just that:
  https://lkml.org/lkml/2015/10/30/419

Cheers,
Jeff

>> [    0.128000] blk_update_request: I/O error, dev vda, sector 0
>> [    0.128000] Buffer I/O error on dev vda, logical block 0, lost async page write
>> [    0.128000] blk_update_request: I/O error, dev vda, sector 8
>> [    0.128000] Buffer I/O error on dev vda, logical block 1, lost async page write
>> [    0.128000] blk_update_request: I/O error, dev vda, sector 528
>> [    0.128000] Buffer I/O error on dev vda, logical block 66, lost async page write
>> [    0.128000] blk_update_request: I/O error, dev vda, sector 1824
>> [    0.128000] Buffer I/O error on dev vda, logical block 228, lost async page write
>> [    0.128000] blk_update_request: I/O error, dev vda, sector 1864
>> [    0.128000] Buffer I/O error on dev vda, logical block 233, lost async page write
>> [    0.128000] blk_update_request: I/O error, dev vda, sector 41840
>> [    0.128000] Buffer I/O error on dev vda, logical block 5230, lost async page write
>> [    0.128000] blk_update_request: I/O error, dev vda, sector 262672
>> [    0.128000] Buffer I/O error on dev vda, logical block 32834, lost async page write
>> [    0.128000] blk_update_request: I/O error, dev vda, sector 262680
>> [    0.128000] Buffer I/O error on dev vda, logical block 32835, lost async page write
>> [    0.128000] blk_update_request: I/O error, dev vda, sector 262752
>> [    0.128000] Buffer I/O error on dev vda, logical block 32844, lost async page write
>> [    0.128000] blk_update_request: I/O error, dev vda, sector 262792
>> [    0.128000] Buffer I/O error on dev vda, logical block 32849, lost async page write
>> [    0.132000] JBD2: recovery failed
>> [    0.132000] EXT4-fs (vda): error loading journal
>> [    0.132000] ------------[ cut here ]------------
>> [    0.132000] WARNING: CPU: 0 PID: 1 at fs/block_dev.c:58 __blkdev_put+0x16f/0x1b0()
>> [    0.132000] Call Trace:
>> [    0.132000] 00007fd99262db68:  [<0040673d>] warn_slowpath_common+0x7d/0xb0
>> [    0.132000] 00007fd99262dba8:  [<004068d5>] warn_slowpath_null+0x15/0x20
>> [    0.132000] 00007fd99262dbb8:  [<0048efbf>] __blkdev_put+0x16f/0x1b0
>> [    0.132000] 00007fd99262dbf8:  [<0048fcd2>] blkdev_put+0x92/0x110
>> [    0.132000] 00007fd99262dc28:  [<00462faf>] kill_block_super+0x3f/0x70
>> [    0.132000] 00007fd99262dc48:  [<00461bf2>] deactivate_locked_super+0x52/0xb0
>> [    0.132000] 00007fd99262dc78:  [<00462f51>] mount_bdev+0x1b1/0x1d0
>> [    0.132000] 00007fd99262dc80:  [<004c5c40>] ext4_fill_super+0x0/0x32f0
>> [    0.132000] 00007fd99262dce8:  [<004c16f0>] ext4_mount+0x10/0x20
>> [    0.132000] 00007fd99262dcf8:  [<00463164>] mount_fs+0x14/0xc0
>> [    0.132000] 00007fd99262dd28:  [<0047a38e>] vfs_kern_mount+0x5e/0x120
>> [    0.132000] 00007fd99262dd78:  [<0047baa8>] do_mount+0x208/0xd90
>> [    0.132000] 00007fd99262dd88:  [<0045d7db>] __kmalloc_track_caller+0x18b/0x1c0
>> [    0.132000] 00007fd99262dd98:  [<00450618>] strndup_user+0x48/0x60
>> [    0.132000] 00007fd99262de08:  [<00450618>] strndup_user+0x48/0x60
>> [    0.132000] 00007fd99262de48:  [<0047c99a>] SyS_mount+0x6a/0xb0
>> [    0.132000] 00007fd99262de98:  [<00403b89>] run_syscalls+0xd9/0x1c0
>> [    0.132000] 00007fd99262deb0:  [<00425970>] autoremove_wake_function+0x0/0x40
>> [    0.132000] 00007fd99262dec8:  [<005535f0>] kernel_init+0x0/0xf0
>> [    0.132000] 00007fd99262dee8:  [<005535f0>] kernel_init+0x0/0xf0
>> [    0.132000] 00007fd99262df08:  [<00402f2d>] run_init_process+0x1d/0x40
>> [    0.132000] 00007fd99262df18:  [<00553626>] kernel_init+0x36/0xf0
>> [    0.132000] 00007fd99262df28:  [<00403158>] thread_bootstrap+0x48/0x50
>> [    0.132000]
>> [    0.132000] ---[ end trace 0b886a9a044a4995 ]---
>> 
>> Thanks,
>> //richard
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web