All of lore.kernel.org
 help / color / mirror / Atom feed
* [bug] mkfs.ext[23] hangs on loop device (aarch64, 5.8+)
       [not found] <94883604.6936811.1596720770623.JavaMail.zimbra@redhat.com>
@ 2020-08-06 17:47 ` Jan Stancek
  2020-08-18  2:29   ` Ming Lei
  0 siblings, 1 reply; 5+ messages in thread
From: Jan Stancek @ 2020-08-06 17:47 UTC (permalink / raw)
  To: linux-block

Hi,

I'm seeing sporadic mkfs.ext[23] hangs on loop device while running various
LTP tests. It seems to hang indefinitely once in bad state:
  0 D root       29782   29761  0  80   0 -  1006 rq_qos 15:09 ?        00:00:00             mkfs.ext3 /dev/loop0

[19809.932566] mkfs.ext3       D    0 29782  29761 0x00000000 
[19809.934000] Call trace: 
[19809.934624]  __switch_to+0xfc/0x150 
[19809.935533]  __schedule+0x364/0x828 
[19809.936432]  schedule+0x58/0xe0 
[19809.937261]  io_schedule+0x24/0xc0 
[19809.938144]  rq_qos_wait+0xe4/0x150 
[19809.939044]  wbt_wait+0x98/0xd8 
[19809.939864]  __rq_qos_throttle+0x38/0x50 
[19809.940847]  blk_mq_submit_bio+0x108/0x620 
[19809.941890]  submit_bio_noacct+0x358/0x3d8 
[19809.942909]  submit_bio+0x40/0x1a8 
[19809.943770]  submit_bh_wbc+0x16c/0x1e8 
[19809.944701]  __block_write_full_page+0x238/0x5c8 
[19809.945862]  block_write_full_page+0x124/0x138 
[19809.947000]  blkdev_writepage+0x24/0x30 
[19809.948031]  __writepage+0x28/0xc8 
[19809.948905]  write_cache_pages+0x1ac/0x410 
[19809.949988]  generic_writepages+0x4c/0x88 
[19809.950947]  blkdev_writepages+0x18/0x28 
[19809.951934]  do_writepages+0x40/0xe8 
[19809.952856]  __filemap_fdatawrite_range+0xe0/0x150 
[19809.954066]  file_write_and_wait_range+0x9c/0x108 
[19809.955266]  blkdev_fsync+0x24/0x50 
[19809.956170]  vfs_fsync_range+0x3c/0x88 
[19809.957126]  do_fsync+0x44/0x90 
[19809.957925]  __arm64_sys_fsync+0x20/0x30 
[19809.958961]  el0_svc_common.constprop.0+0x7c/0x188 
[19809.960242]  do_el0_svc+0x2c/0x98 
[19809.961028]  el0_sync_handler+0x84/0x110 
[19809.962003]  el0_sync+0x15c/0x180 

It started happening in recent weeks and appears to be aarch64 exclusive so far.

Affected kernels are at least:
  v5.8-475-g382625d0d432
  v5.8-607-gcdc8fcb49905
  v5.8-rc2-87-g6b7b181b67aa
  v5.8-rc2-105-g492d76b21566

6b7b181b67aa is the oldest commit I could reproduce it with, but my current
reproducer (running LTP fgetxattr01 in loop for 30 minutes) doesn't look very
reliable for bisect. 

Does this ring any bells?

Thanks,
Jan


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [bug] mkfs.ext[23] hangs on loop device (aarch64, 5.8+)
  2020-08-06 17:47 ` [bug] mkfs.ext[23] hangs on loop device (aarch64, 5.8+) Jan Stancek
@ 2020-08-18  2:29   ` Ming Lei
  2020-08-18  6:19     ` Jan Stancek
  0 siblings, 1 reply; 5+ messages in thread
From: Ming Lei @ 2020-08-18  2:29 UTC (permalink / raw)
  To: Jan Stancek; +Cc: linux-block

On Thu, Aug 06, 2020 at 01:47:33PM -0400, Jan Stancek wrote:
> Hi,
> 
> I'm seeing sporadic mkfs.ext[23] hangs on loop device while running various
> LTP tests. It seems to hang indefinitely once in bad state:
>   0 D root       29782   29761  0  80   0 -  1006 rq_qos 15:09 ?        00:00:00             mkfs.ext3 /dev/loop0
> 
> [19809.932566] mkfs.ext3       D    0 29782  29761 0x00000000 
> [19809.934000] Call trace: 
> [19809.934624]  __switch_to+0xfc/0x150 
> [19809.935533]  __schedule+0x364/0x828 
> [19809.936432]  schedule+0x58/0xe0 
> [19809.937261]  io_schedule+0x24/0xc0 
> [19809.938144]  rq_qos_wait+0xe4/0x150 
> [19809.939044]  wbt_wait+0x98/0xd8 
> [19809.939864]  __rq_qos_throttle+0x38/0x50 
> [19809.940847]  blk_mq_submit_bio+0x108/0x620 
> [19809.941890]  submit_bio_noacct+0x358/0x3d8 
> [19809.942909]  submit_bio+0x40/0x1a8 
> [19809.943770]  submit_bh_wbc+0x16c/0x1e8 
> [19809.944701]  __block_write_full_page+0x238/0x5c8 
> [19809.945862]  block_write_full_page+0x124/0x138 
> [19809.947000]  blkdev_writepage+0x24/0x30 
> [19809.948031]  __writepage+0x28/0xc8 
> [19809.948905]  write_cache_pages+0x1ac/0x410 
> [19809.949988]  generic_writepages+0x4c/0x88 
> [19809.950947]  blkdev_writepages+0x18/0x28 
> [19809.951934]  do_writepages+0x40/0xe8 
> [19809.952856]  __filemap_fdatawrite_range+0xe0/0x150 
> [19809.954066]  file_write_and_wait_range+0x9c/0x108 
> [19809.955266]  blkdev_fsync+0x24/0x50 
> [19809.956170]  vfs_fsync_range+0x3c/0x88 
> [19809.957126]  do_fsync+0x44/0x90 
> [19809.957925]  __arm64_sys_fsync+0x20/0x30 
> [19809.958961]  el0_svc_common.constprop.0+0x7c/0x188 
> [19809.960242]  do_el0_svc+0x2c/0x98 
> [19809.961028]  el0_sync_handler+0x84/0x110 
> [19809.962003]  el0_sync+0x15c/0x180 
> 
> It started happening in recent weeks and appears to be aarch64 exclusive so far.
> 
> Affected kernels are at least:
>   v5.8-475-g382625d0d432
>   v5.8-607-gcdc8fcb49905
>   v5.8-rc2-87-g6b7b181b67aa
>   v5.8-rc2-105-g492d76b21566
> 
> 6b7b181b67aa is the oldest commit I could reproduce it with, but my current
> reproducer (running LTP fgetxattr01 in loop for 30 minutes) doesn't look very
> reliable for bisect. 
> 
> Does this ring any bells?

I saw this kind io hang in ltp/fs_fill test reliably and the loop is
over image in tmpfs:

https://lkml.org/lkml/2020/7/26/77

And I have verified that the following patch can fix the issue:

https://lore.kernel.org/linux-block/bc5fa941-3b7c-f28e-dd46-1a1d6e5c40a8@kernel.dk/T/#t


Thanks,
Ming


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [bug] mkfs.ext[23] hangs on loop device (aarch64, 5.8+)
  2020-08-18  2:29   ` Ming Lei
@ 2020-08-18  6:19     ` Jan Stancek
  2020-08-19  6:37       ` Jan Stancek
  0 siblings, 1 reply; 5+ messages in thread
From: Jan Stancek @ 2020-08-18  6:19 UTC (permalink / raw)
  To: Ming Lei; +Cc: linux-block



----- Original Message -----
> I saw this kind io hang in ltp/fs_fill test reliably and the loop is
> over image in tmpfs:
> 
> https://lkml.org/lkml/2020/7/26/77
> 
> And I have verified that the following patch can fix the issue:
> 
> https://lore.kernel.org/linux-block/bc5fa941-3b7c-f28e-dd46-1a1d6e5c40a8@kernel.dk/T/#t

Thanks, I'll test your patch with my setup.

In my case, I traced requests going up to blk_mq_sched_insert_requests(),
but they never made it to loop driver code (loop_queue_rq / lo_complete_rq),
so I assumed they are getting lost somewhere in mq scheduling.

After hang, there were always several requests stuck "inflight":
# cat /sys/kernel/debug/block/loop0/rqos/wbt/inflight
0: inflight 41
1: inflight 0
2: inflight 0

With some additional traces I could see requests being at dispatch list
and state == 0, which appears to fit description of problem you've seen:

  blk_mq_sched_insert_requests: blk_mq_sched_insert_requests hctx: ffff000168598000, ctx: fffffdffbff16dc0
  wbt_wait: wbt_wait rqos: ffff00016a5e1358, rqw: ffff00016a5e1388, bio: ffff0000da6bbd00, inflight: 41
  <wbt_wait goes to sleep>

crash> bio.bi_disk ffff0000da6bbd00
  bi_disk = 0xffff000168599800
crash> gendisk.disk_name 0xffff000168599800
  disk_name = "loop0\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000" 

crash> blk_mq_hw_ctx.queue 0xffff000168598000
  queue = 0xffff000117c06800
crash> request_queue.rq_qos 0xffff000117c06800
  rq_qos = 0xffff00016a5e1358

crash> blk_mq_hw_ctx.state 0xffff000168598000
    state = 0
crash> list blk_mq_hw_ctx.dispatch -h 0xffff000168598000 | wc -l
42

Regards,
Jan


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [bug] mkfs.ext[23] hangs on loop device (aarch64, 5.8+)
  2020-08-18  6:19     ` Jan Stancek
@ 2020-08-19  6:37       ` Jan Stancek
  2020-08-21  9:45         ` [LTP] Fwd: " Jan Stancek
  0 siblings, 1 reply; 5+ messages in thread
From: Jan Stancek @ 2020-08-19  6:37 UTC (permalink / raw)
  To: Ming Lei; +Cc: linux-block



----- Original Message -----
> 
> 
> ----- Original Message -----
> > I saw this kind io hang in ltp/fs_fill test reliably and the loop is
> > over image in tmpfs:
> > 
> > https://lkml.org/lkml/2020/7/26/77
> > 
> > And I have verified that the following patch can fix the issue:
> > 
> > https://lore.kernel.org/linux-block/bc5fa941-3b7c-f28e-dd46-1a1d6e5c40a8@kernel.dk/T/#t
> 
> Thanks, I'll test your patch with my setup.

I've seen no hangs over past ~24 hours with patch above.

Thanks,
Jan


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [LTP] Fwd: [bug] mkfs.ext[23] hangs on loop device (aarch64, 5.8+)
  2020-08-19  6:37       ` Jan Stancek
@ 2020-08-21  9:45         ` Jan Stancek
  0 siblings, 0 replies; 5+ messages in thread
From: Jan Stancek @ 2020-08-21  9:45 UTC (permalink / raw)
  To: ltp

> > ----- Original Message -----
> > > I saw this kind io hang in ltp/fs_fill test reliably and the loop is
> > > over image in tmpfs:
> > > 
> > > https://lkml.org/lkml/2020/7/26/77
> > > 
> > > And I have verified that the following patch can fix the issue:
> > > 
> > > https://lore.kernel.org/linux-block/bc5fa941-3b7c-f28e-dd46-1a1d6e5c40a8@kernel.dk/T/#t
> > 
> > Thanks, I'll test your patch with my setup.
> 
> I've seen no hangs over past ~24 hours with patch above.
> 
> Thanks,
> Jan

fyi, in case you see sporadic I/O hangs, usually while running LTP tests
that make use of loop device with recent upstream kernels:
  https://lore.kernel.org/linux-block/1929570063.6965184.1596736053281.JavaMail.zimbra@redhat.com/


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-08-21  9:45 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <94883604.6936811.1596720770623.JavaMail.zimbra@redhat.com>
2020-08-06 17:47 ` [bug] mkfs.ext[23] hangs on loop device (aarch64, 5.8+) Jan Stancek
2020-08-18  2:29   ` Ming Lei
2020-08-18  6:19     ` Jan Stancek
2020-08-19  6:37       ` Jan Stancek
2020-08-21  9:45         ` [LTP] Fwd: " Jan Stancek

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.