Fixed issue with processing of EC_dev_remove event

The pool guid and vdev guid received by zfs_agent_post_event(),
which calls zfs_retire_recv(), are normally non-zero.  However,
later in this same method they may be unconditionally reset to
zero by the code which is intended to handle  multipath, spare
and l2arc vdevs.  This will result in the EC_dev_remove not
being handled.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>\
Co-authored-by: Vipin Kumar Verma <vipin.verma@hpe.com>
Signed-off-by: Srikanth N S <srikanth.nagasubbaraoseetharaman@hpe.com>
Closes #11564
This commit is contained in:
nssrikanth 2021-02-05 22:00:50 +05:30 committed by GitHub
parent d66f017c17
commit 32366649d3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 6 deletions

View File

@ -13,6 +13,7 @@
/* /*
* Copyright (c) 2016, Intel Corporation. * Copyright (c) 2016, Intel Corporation.
* Copyright (c) 2018, loli10K <ezomori.nozomu@gmail.com> * Copyright (c) 2018, loli10K <ezomori.nozomu@gmail.com>
* Copyright (c) 2021 Hewlett Packard Enterprise Development LP
*/ */
#include <libnvpair.h> #include <libnvpair.h>
@ -211,12 +212,18 @@ zfs_agent_post_event(const char *class, const char *subclass, nvlist_t *nvl)
* For multipath, spare and l2arc devices ZFS_EV_VDEV_GUID or * For multipath, spare and l2arc devices ZFS_EV_VDEV_GUID or
* ZFS_EV_POOL_GUID may be missing so find them. * ZFS_EV_POOL_GUID may be missing so find them.
*/ */
(void) nvlist_lookup_string(nvl, DEV_IDENTIFIER, if (pool_guid == 0 || vdev_guid == 0) {
&search.gs_devid); if ((nvlist_lookup_string(nvl, DEV_IDENTIFIER,
(void) zpool_iter(g_zfs_hdl, zfs_agent_iter_pool, &search); &search.gs_devid) == 0) &&
pool_guid = search.gs_pool_guid; (zpool_iter(g_zfs_hdl, zfs_agent_iter_pool, &search)
vdev_guid = search.gs_vdev_guid; == 1)) {
devtype = search.gs_vdev_type; if (pool_guid == 0)
pool_guid = search.gs_pool_guid;
if (vdev_guid == 0)
vdev_guid = search.gs_vdev_guid;
devtype = search.gs_vdev_type;
}
}
/* /*
* We want to avoid reporting "remove" events coming from * We want to avoid reporting "remove" events coming from