All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: Song Liu <song@kernel.org>,
	linux-raid@vger.kernel.org, "yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH] md: do not require mddev_lock() for all options
Date: Mon, 25 Sep 2023 09:58:35 +0200	[thread overview]
Message-ID: <20230925095835.00002fcc@linux.intel.com> (raw)
In-Reply-To: <175273eb-35a2-507d-ec0c-0685e7f6acd7@huaweicloud.com>

On Mon, 25 Sep 2023 11:05:42 +0800
Yu Kuai <yukuai1@huaweicloud.com> wrote:

> 在 2023/09/23 5:04, Song Liu 写道:
> > Hi Mariusz,
> > 
> > Sorry for the late reply.
> > 
> > On Wed, Sep 13, 2023 at 1:55 AM Mariusz Tkaczyk
> > <mariusz.tkaczyk@linux.intel.com> wrote:  
> >>
> >> We don't need to lock device to reject not supported request
> >> in array_state_store().
> >> Main motivation is to make a room for action does not require lock yet,
> >> like prepare to stop (see md_ioctl()).  
> > 
> > I made some changes to the commit log:
> > 
> >      md: do not require mddev_lock() for all options
> > 
> >      We don't need to lock device to reject not supported request
> >      in array_state_store().
> >      Main motivation is to make a room for action does not require lock yet,
> >      like prepare to stop (see md_ioctl()).
> > 
> > But I am not sure what you meant by "make a room for action does not
> > require lock yet". Could you please explain?  
> 
> Yes, this sounds confusing, if 'action does not require lock', then it
> shound not be blocked by array_state_store() with or without this patch.

In md_ioctl() we do some actions before stopping. We are verifying
how many holders are there (mddev->openers), we are setting MD_CLOSING and
sync_blockdev() is executed. I see that it is omitted in array_state_store().
https://elixir.bootlin.com/linux/latest/source/drivers/md/md.c#L7580

I meant that with this separated switch before locking mddev it is now easy to
add other actions, like mentioned code above for stopping.
> 
> > 
> > Otherwise, the code looks reasonable to me.  
> 
> Changes look good to me, after clarify commit message, feel free to add
> 
> Reviewed-by: Yu Kuai <yukuai3@huawei.com>

Thanks!
I will send v2.

Mariusz

      reply	other threads:[~2023-09-25  7:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13  8:55 [PATCH] md: do not require mddev_lock() for all options Mariusz Tkaczyk
2023-09-22 21:04 ` Song Liu
2023-09-25  3:05   ` Yu Kuai
2023-09-25  7:58     ` Mariusz Tkaczyk [this message]

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=20230925095835.00002fcc@linux.intel.com \
    --to=mariusz.tkaczyk@linux.intel.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=song@kernel.org \
    --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 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.