All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Coly Li <colyli@suse.de>
Cc: linux-raid@vger.kernel.org,
	Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>,
	Jes Sorensen <jes@trained-monkey.org>
Subject: Re: [PATCH v3] Incremental: remove obsoleted calls to udisks
Date: Tue, 30 May 2023 08:17:18 +0200	[thread overview]
Message-ID: <20230530081718.00003cb7@linux.intel.com> (raw)
In-Reply-To: <20230529160754.26849-1-colyli@suse.de>

On Tue, 30 May 2023 00:07:54 +0800
Coly Li <colyli@suse.de> wrote:

> Utilility udisks is removed from udev upstream, calling this obsoleted
> command in run_udisks() doesn't make any sense now.
> 
> This patch removes the calls chain of udisks, which includes routines
> run_udisk(), force_remove(), and 2 locations where force_remove() are
> called. Considering force_remove() is removed with udisks util, it is
> fair to remove Manage_stop() inside force_remove() as well.
> 
> In the two modifications where calling force_remove() are removed,
> the failure from Manage_subdevs() can be safely ignored, because,
> 1) udisks doesn't exist, no need to check the return value to umount
>    the file system by udisks and remove the component disk again.
> 2) After the 'I' inremental remove, there is another 'r' hot remove
>    following up. The first incremental remove is a best-try effort.
Hi Coly,

I'm not sure what you meant here. I know that on "remove" event udev will call
mdadm -If <devname>. And that is all I'm familiar with. I don't see another
branch executed in code to handle "remove" event, no second attempt for clean
up is made. Could you clarify? How is it executed?
Perhaps, I understand it incorrectly as second action that is always executed
automatically. I know that there is an action "--remove" which can be manually
triggered. Is that what you meant?

> Therefore in this patch, where force_remove() is removed, the return
> value of calling Manage_subdevs() is not checked too.
> 
> Signed-off-by: Coly Li <colyli@suse.de>
> Cc: Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>
> Cc: Jes Sorensen <jes@trained-monkey.org>
> ---
> Changelog,
> v3: remove the almost-useless warning message, and make the change
>     more simplified.
> v2: improve based on code review comments from Mariusz.
> v1: initial version.

For the code:
Reviewed-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>

Mariusz

  reply	other threads:[~2023-05-30  6:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-29 16:07 [PATCH v3] Incremental: remove obsoleted calls to udisks Coly Li
2023-05-30  6:17 ` Mariusz Tkaczyk [this message]
2023-05-30 10:59   ` Coly Li
2023-05-30 13:05     ` Mariusz Tkaczyk
2023-05-30 13:10       ` Coly Li

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=20230530081718.00003cb7@linux.intel.com \
    --to=mariusz.tkaczyk@linux.intel.com \
    --cc=colyli@suse.de \
    --cc=jes@trained-monkey.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=mariusz.tkaczyk@intel.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.