mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
To: Yu Kuai <yukuai1@huaweicloud.com>, Song Liu <song@kernel.org>,
	 linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
	"yukuai (C)" <yukuai3@huawei.com>,
	"yangerkun@huawei.com" <yangerkun@huawei.com>
Subject: Re: Lockup of (raid5 or raid6) + vdo after taking out a disk under load
Date: Fri, 12 Jul 2024 15:11:42 +0300	[thread overview]
Message-ID: <29d69e586e628ef2e5f2fd7b9fe4e7062ff36ccf.camel@yandex.ru> (raw)
In-Reply-To: <1f879e67-4d64-4df0-5817-360d84ff8b89@huaweicloud.com>

On Fri, 2024-07-12 at 16:35 +0800, Yu Kuai wrote:
> Hi,
>
> 在 2024/07/12 14:53, Konstantin Kharlamov 写道:
>
> > # Steps to reproduce
> >
> > 1. Create raid5 LV + VDO by executing a `./mk_lvm_raid5.sh
> > /dev/sdX1
> > /dev/sdY1 /dev/sdZ1` where `mk_lvm_raid5.sh` has the following
> > content:
> >
> >      #!/bin/bash
> >
> >      set -exu
> >
> >      if [ "$#" -ne 3 ]; then
> >          echo "Wrong number of parameters.
> >      Usage: $(basename $0) disk1 disk2 disk3"
> >          exit 1
> >      fi
> >
> >      # create the VG
> >      pvcreate -f "$1" "$2" "$3"
> >      vgcreate p_r5 "$1" "$2" "$3"
> >
> >      # create the LV
> >      lvcreate --type raid5 -i 2 -L 21474836480b -I 64K -n
> > vdo_internal_deco_vol p_r5 -y
> >      lvconvert -y --type vdo-pool --virtualsize 107374182400B -n
> > deco_vol p_r5/vdo_internal_deco_vol
> >
> > 2. Start load by executing `fio ./fio-30%write.fio` with the `fio-
> > 30%write.fio` having the following content:
> >
> >      [test IOPS]
> >      blocksize=8k
> >      filename=/dev/p_r5/deco_vol
> >      filesize=100G
> >      direct=1
> >      buffered=0
> >      ioengine=libaio
> >      iodepth=32
> >      rw=randrw
> >      rwmixwrite=30
> >      numjobs=4
> >      group_reporting
> >      time_based
> >      runtime=99h
> >      clat_percentiles=0
> >      unlink=1
> >
> > 3. Wait for about a minute
> > 4. Remove a disk of the volume group, either physically, or by
> > turning
> > off jbod slot's power (DO NOT use /…/device/delete).
>
> Looks like this is because IO is failed from raid level, and then dm
> level keep retry this IO(This will be related to the step 4), hence
> raid5d stuck in the loop to hanlde new IO.
>
> Can you give the following patch a test to confirm this?
>
> Thanks!
> Kuai
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index c14cf2410365..a0f784cd664c 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -6776,7 +6776,9 @@ static void raid5d(struct md_thread *thread)
>
>                  while ((bio = remove_bio_from_retry(conf, &offset)))
> {
>                          int ok;
> +
>                          spin_unlock_irq(&conf->device_lock);
> +                       cond_resched();
>                          ok = retry_aligned_read(conf, bio, offset);
>                          spin_lock_irq(&conf->device_lock);
>                          if (!ok)
> @@ -6790,11 +6792,11 @@ static void raid5d(struct md_thread *thread)
>                          break;
>                  handled += batch_size;
>
> -               if (mddev->sb_flags & ~(1 << MD_SB_CHANGE_PENDING)) {
> -                       spin_unlock_irq(&conf->device_lock);
> +               spin_unlock_irq(&conf->device_lock);
> +               if (mddev->sb_flags & ~(1 << MD_SB_CHANGE_PENDING))
>                          md_check_recovery(mddev);
> -                       spin_lock_irq(&conf->device_lock);
> -               }
> +               cond_resched();
> +               spin_lock_irq(&conf->device_lock);
>          }
>          pr_debug("%d stripes handled\n", handled);

Thank you for the quick answer! FTR, I had applied the diff by manually
editing the code because tabs got converted to spaces in the text, so
it wasn't applicable. Hopefully I got everything correct. (in
retrospection, I could've used `--ignore-whitespace`. Oh, well…)

So, there are both good and bad news.

Good news: you diff seems to have fixed the problem! I would have to
test more extensively in another environment to be completely sure, but
by following the minimal steps-to-reproduce I can no longer reproduce
the problem, so it seems to have fixed the problem.

Bad news: there's a new lockup now 😄 This one seems to happen after
the disk is returned back; unless the action of returning back matches
accidentally the appearing stacktraces, which still might be possible
even though I re-tested multiple times. It's because the traces 
(below) seems not to always appear. However, even when traces do not
appear, IO load on the fio that's running in the background drops to
zero, so something seems definitely wrong.

    [  475.353727] sd 0:0:25:0: [sdbu] Attached SCSI disk
    [  615.173084] INFO: task dm-vdo0:bioQ0:11500 blocked for more than 122 seconds.
    [  615.173326]       Not tainted 6.9.8-bstrg #4
    [  615.173525] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [  615.173735] task:dm-vdo0:bioQ0   state:D stack:0     pid:11500 tgid:11500 ppid:2      flags:0x00004000
    [  615.173961] Call Trace:
    [  615.174180]  <TASK>
    [  615.174402]  __schedule+0x376/0xb30
    [  615.174636]  schedule+0x2f/0x110
    [  615.174862]  schedule_timeout+0x15a/0x170
    [  615.175092]  ? _raw_spin_unlock_irqrestore+0x1e/0x40
    [  615.175326]  ? __wake_up+0x40/0x60
    [  615.175563]  wait_woken+0x73/0x80
    [  615.175793]  raid5_make_request+0x5dc/0x12f0 [raid456]
    [  615.176033]  ? kmem_cache_alloc+0x4e/0x2f0
    [  615.176257]  ? __pfx_woken_wake_function+0x10/0x10
    [  615.176496]  md_handle_request+0x15e/0x2a0
    [  615.176730]  raid_map+0x31/0x60 [dm_raid]
    [  615.176966]  __map_bio+0x181/0x1b0
    [  615.177203]  dm_submit_bio+0x194/0x550
    [  615.177440]  __submit_bio+0x97/0x130
    [  615.177680]  submit_bio_noacct_nocheck+0x18c/0x3c0
    [  615.177925]  submit_data_vio+0xba/0x100
    [  615.178171]  work_queue_runner+0x215/0x290
    [  615.178416]  ? __pfx_autoremove_wake_function+0x10/0x10
    [  615.178664]  ? __pfx_work_queue_runner+0x10/0x10
    [  615.178914]  kthread+0xff/0x130
    [  615.179168]  ? __pfx_kthread+0x10/0x10
    [  615.179422]  ret_from_fork+0x30/0x50
    [  615.179687]  ? __pfx_kthread+0x10/0x10
    [  615.179947]  ret_from_fork_asm+0x1a/0x30
    [  615.180215]  </TASK>
    [  615.180475] INFO: task dm-vdo0:bioQ1:11501 blocked for more than 122 seconds.
    [  615.180750]       Not tainted 6.9.8-bstrg #4
    [  615.181028] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [  615.181319] task:dm-vdo0:bioQ1   state:D stack:0     pid:11501 tgid:11501 ppid:2      flags:0x00004000
    [  615.181624] Call Trace:
    [  615.181926]  <TASK>
    [  615.182228]  __schedule+0x376/0xb30
    [  615.182529]  schedule+0x2f/0x110
    [  615.182821]  schedule_timeout+0x15a/0x170
    [  615.183117]  ? _raw_spin_unlock_irqrestore+0x1e/0x40
    [  615.183410]  ? __wake_up+0x40/0x60
    [  615.183701]  wait_woken+0x73/0x80
    [  615.183987]  raid5_make_request+0x5dc/0x12f0 [raid456]
    [  615.184280]  ? mempool_alloc+0x61/0x1b0
    [  615.184565]  ? kmem_cache_alloc+0x4e/0x2f0
    [  615.184845]  ? __pfx_woken_wake_function+0x10/0x10
    [  615.185126]  md_handle_request+0x15e/0x2a0
    [  615.185402]  raid_map+0x31/0x60 [dm_raid]
    [  615.185695]  __map_bio+0x181/0x1b0
    [  615.185979]  dm_submit_bio+0x194/0x550
    [  615.186255]  __submit_bio+0x97/0x130
    [  615.186529]  submit_bio_noacct_nocheck+0x18c/0x3c0
    [  615.186804]  submit_data_vio+0xba/0x100
    [  615.187076]  work_queue_runner+0x215/0x290
    [  615.187350]  ? __pfx_autoremove_wake_function+0x10/0x10
    [  615.187628]  ? __pfx_work_queue_runner+0x10/0x10
    [  615.187905]  kthread+0xff/0x130
    [  615.188180]  ? __pfx_kthread+0x10/0x10
    [  615.188456]  ret_from_fork+0x30/0x50
    [  615.188729]  ? __pfx_kthread+0x10/0x10
    [  615.189002]  ret_from_fork_asm+0x1a/0x30
    [  615.189276]  </TASK>
    [  615.189541] INFO: task dm-vdo0:bioQ3:11504 blocked for more than 122 seconds.
    [  615.189823]       Not tainted 6.9.8-bstrg #4
    [  615.190102] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [  615.190392] task:dm-vdo0:bioQ3   state:D stack:0     pid:11504 tgid:11504 ppid:2      flags:0x00004000
    [  615.190694] Call Trace:
    [  615.190989]  <TASK>
    [  615.191283]  __schedule+0x376/0xb30
    [  615.191580]  schedule+0x2f/0x110
    [  615.191875]  schedule_timeout+0x15a/0x170
    [  615.192168]  ? _raw_spin_unlock_irqrestore+0x1e/0x40
    [  615.192463]  ? __wake_up+0x40/0x60
    [  615.192757]  wait_woken+0x73/0x80
    [  615.193057]  raid5_make_request+0x5dc/0x12f0 [raid456]
    [  615.193365]  ? mempool_alloc+0x61/0x1b0
    [  615.193663]  ? kmem_cache_alloc+0x4e/0x2f0
    [  615.193961]  ? __pfx_woken_wake_function+0x10/0x10
    [  615.194257]  md_handle_request+0x15e/0x2a0
    [  615.194548]  raid_map+0x31/0x60 [dm_raid]
    [  615.194836]  __map_bio+0x181/0x1b0
    [  615.195114]  dm_submit_bio+0x194/0x550
    [  615.195386]  __submit_bio+0x97/0x130
    [  615.195657]  submit_bio_noacct_nocheck+0x18c/0x3c0
    [  615.195932]  submit_data_vio+0xba/0x100
    [  615.196206]  work_queue_runner+0x215/0x290
    [  615.196488]  ? __pfx_autoremove_wake_function+0x10/0x10
    [  615.196767]  ? __pfx_work_queue_runner+0x10/0x10
    [  615.197044]  kthread+0xff/0x130
    [  615.197321]  ? __pfx_kthread+0x10/0x10
    [  615.197596]  ret_from_fork+0x30/0x50
    [  615.197868]  ? __pfx_kthread+0x10/0x10
    [  615.198141]  ret_from_fork_asm+0x1a/0x30
    [  615.198415]  </TASK>

  reply	other threads:[~2024-07-12 12:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-12  6:53 Konstantin Kharlamov
2024-07-12  8:35 ` Yu Kuai
2024-07-12 12:11   ` Konstantin Kharlamov [this message]
2024-07-13 11:06     ` Yu Kuai
2024-07-13 13:50       ` Konstantin Kharlamov
2024-07-15  1:56         ` Yu Kuai
2024-07-22 17:56           ` Konstantin Kharlamov
2024-07-23 14:34             ` Konstantin Kharlamov
2024-07-31 14:14             ` Konstantin Kharlamov
2024-07-31 20:41               ` Bryan Gurney
2024-08-01 14:46                 ` Konstantin Kharlamov
2024-07-31 21:33               ` Matthew Sakai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29d69e586e628ef2e5f2fd7b9fe4e7062ff36ccf.camel@yandex.ru \
    --to=hi-angel@yandex.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=song@kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=yukuai1@huaweicloud.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®