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@xxxxxxx>
> ---
> 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@xxxxxxxx>, 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
