From: Martin Wilck <mwilck@suse.com>
To: Wuchongyun <wu.chongyun@h3c.com>,
Benjamin Marzinski <bmarzins@redhat.com>,
"dm-devel@redhat.com" <dm-devel@redhat.com>
Cc: Guozhonghua <guozhonghua@h3c.com>,
Changwei Ge <ge.changwei@h3c.com>,
Changlimin <changlimin@h3c.com>
Subject: Re: [PATCH] multipathd: update path's udev in uev_update_path
Date: Mon, 22 Jan 2018 11:34:15 +0100 [thread overview]
Message-ID: <1516617255.30796.40.camel@suse.com> (raw)
In-Reply-To: <CEB9978CF3252343BE3C67AC9F0086A3429585CA@H3CMLB14-EX.srv.huawei-3com.com>
On Sat, 2018-01-20 at 02:30 +0000, Wuchongyun wrote:
> Hi Martin and Ben,
> Could you help to review this patch, thanks.
>
> When receiving a change uevent and calling uev_update_path, current
> code
> not update the path's udev, if use pp->udev to query the udev
> database
> info will get the old data. So it should update the path's udev with
> the
> new udev from the new uevent in uev_update_path also.
>
> Signed-off-by: Chongyun Wu <wu.chongyun@h3c.com>
> ---
> multipathd/main.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/multipathd/main.c b/multipathd/main.c
> index 27cf234..e7a4f4b 100644
> --- a/multipathd/main.c
> +++ b/multipathd/main.c
> @@ -937,6 +937,9 @@ uev_update_path (struct uevent *uev, struct
> vectors * vecs)
> if (pp) {
> struct multipath *mpp = pp->mpp;
>
> + udev_device_unref(pp->udev);
> + pp->udev = udev_device_ref(uev->udev);
> +
> if (disable_changed_wwids &&
> (strlen(pp->wwid) || pp->wwid_changed)) {
> char wwid[WWID_SIZE];
The general idea is correct, but I fear we need to do more.
Basically, if relevant udev properties have changed, we need to call
pathinfo() on the changed path. Getting this right is subtle, I guess.
We can't simply change the path properties in the pathvec, because
there'll be locking issues, and changed path properties might affect
how the path is handled. The path may have gone R/O, or even have
changed wwid. The safest course of action might be to delete and re-add
the path if any important properties have changed. But blindly deleting
and re-adding would be wrong as well...
Ben has recently done work in this area, so I'll leave the verdict to
him for now.
@Ben, AFAICS this patch shows that disable_changed_wwids won't work
correctly as long as the WWID is derived from udev, which is the
default case these days. Or am I overlooking something?
Martin
> --
> 1.7.9.5
>
> Regards
> Chongyun
--
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2018-01-22 10:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-20 2:30 [PATCH] multipathd: update path's udev in uev_update_path Wuchongyun
2018-01-22 10:34 ` Martin Wilck [this message]
2018-01-23 12:39 ` Benjamin Marzinski
2018-01-23 15:27 ` Martin Wilck
-- strict thread matches above, loose matches on Subject: below --
2018-01-24 1:43 Wuchongyun
2018-01-25 14:22 ` Benjamin Marzinski
2018-01-26 1:52 Wuchongyun
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=1516617255.30796.40.camel@suse.com \
--to=mwilck@suse.com \
--cc=bmarzins@redhat.com \
--cc=changlimin@h3c.com \
--cc=dm-devel@redhat.com \
--cc=ge.changwei@h3c.com \
--cc=guozhonghua@h3c.com \
--cc=wu.chongyun@h3c.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.