All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guoqing Jiang <guoqing.jiang@linux.dev>
To: Song Liu <song@kernel.org>
Cc: Donald Buczek <buczek@molgen.mpg.de>,
	Logan Gunthorpe <logang@deltatee.com>,
	linux-raid <linux-raid@vger.kernel.org>
Subject: Re: [PATCH V2] md: unlock mddev before reap sync_thread in action_store
Date: Thu, 23 Jun 2022 09:29:46 +0800	[thread overview]
Message-ID: <c8fd5b4f-58c7-e85b-f3ba-f3d8a519a059@linux.dev> (raw)
In-Reply-To: <CAPhsuW5SGxiosMw28km7v7bM9qSDRGbLFvyyH1nsAPg2_RcZgA@mail.gmail.com>



On 6/23/22 7:32 AM, Song Liu wrote:
> On Mon, Jun 20, 2022 at 8:11 PM Guoqing Jiang <guoqing.jiang@linux.dev> wrote:
>> Since the bug which commit 8b48ec23cc51a ("md: don't unregister sync_thread
>> with reconfig_mutex held") fixed is related with action_store path, other
>> callers which reap sync_thread didn't need to be changed.
>>
>> Let's pull md_unregister_thread from md_reap_sync_thread, then fix previous
>> bug with belows.
>>
>> 1. unlock mddev before md_reap_sync_thread in action_store.
>> 2. save reshape_position before unlock, then restore it to ensure position
>>     not changed accidentally by others.
>>
>> Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev>
>> ---
>> V2 changes:
>> 1. add set_bit(MD_RECOVERY_INTR, &mddev->recovery) before unregister sync thread
>>
>> And I didn't find regression with this version after run mdadm tests.
>>
>>   drivers/md/dm-raid.c |  1 +
>>   drivers/md/md.c      | 19 +++++++++++++++++--
>>   2 files changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
>> index 9526ccbedafb..d43b8075c055 100644
>> --- a/drivers/md/dm-raid.c
>> +++ b/drivers/md/dm-raid.c
>> @@ -3725,6 +3725,7 @@ static int raid_message(struct dm_target *ti, unsigned int argc, char **argv,
>>          if (!strcasecmp(argv[0], "idle") || !strcasecmp(argv[0], "frozen")) {
>>                  if (mddev->sync_thread) {
>>                          set_bit(MD_RECOVERY_INTR, &mddev->recovery);
>> +                       md_unregister_thread(&mddev->sync_thread);
>>                          md_reap_sync_thread(mddev);
>>                  }
>>          } else if (decipher_sync_action(mddev, mddev->recovery) != st_idle)
>> diff --git a/drivers/md/md.c b/drivers/md/md.c
>> index c7ecb0bffda0..04bab0511312 100644
>> --- a/drivers/md/md.c
>> +++ b/drivers/md/md.c
>> @@ -4830,6 +4830,19 @@ action_store(struct mddev *mddev, const char *page, size_t len)
>>                          if (work_pending(&mddev->del_work))
>>                                  flush_workqueue(md_misc_wq);
>>                          if (mddev->sync_thread) {
>> +                               sector_t save_rp = mddev->reshape_position;
>> +
>> +                               mddev_unlock(mddev);
>> +                               set_bit(MD_RECOVERY_INTR, &mddev->recovery);
>> +                               md_unregister_thread(&mddev->sync_thread);
>> +                               mddev_lock_nointr(mddev);
>> +                               /*
>> +                                * set RECOVERY_INTR again and restore reshape
>> +                                * position in case others changed them after
>> +                                * got lock, eg, reshape_position_store and
>> +                                * md_check_recovery.
>> +                                */
> Hmm.. do we really need to handle reshape_position changed case? What would
> break if we don't?

I want to make the behavior consistent with previous code, and 
reshape_position_store
can change it as said in comment.

Anyway, I didn't see regression with mdadm test with or without setting 
reshape_position,
so it is a more conservative way to avoid potential issue. I will remove 
it if you think it is
not necessary.

Thanks,
Guoqing

  reply	other threads:[~2022-06-23  1:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-21  3:11 [PATCH V2] md: unlock mddev before reap sync_thread in action_store Guoqing Jiang
2022-06-22 23:32 ` Song Liu
2022-06-23  1:29   ` Guoqing Jiang [this message]
2022-06-23  4:12     ` Song Liu

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=c8fd5b4f-58c7-e85b-f3ba-f3d8a519a059@linux.dev \
    --to=guoqing.jiang@linux.dev \
    --cc=buczek@molgen.mpg.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=song@kernel.org \
    /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 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.