On Thu, 2024-10-31 at 14:32 -0400, Benjamin Marzinski wrote:
> if libmp_mapinfo() is run on a device that has a multipath prefixed
> DM
> UUID but no table (either active or inactive), it will now return
> with a
> new exit code, DMP_BAD_DEV, to signal that this is an invalid
> multipath
> device. Currently all code paths treat this identically to
> DMP_NOT_FOUND.
>
> Signed-off-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
> ---
> libmultipath/devmapper.c | 18 ++++++++++++++++++
> libmultipath/devmapper.h | 5 ++++-
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/libmultipath/devmapper.c b/libmultipath/devmapper.c
> index 13d8c1e5..6e11d5b5 100644
> --- a/libmultipath/devmapper.c
> +++ b/libmultipath/devmapper.c
> @@ -726,6 +726,22 @@ static int libmp_mapinfo__(int flags, mapid_t
> id, mapinfo_t info, const char *ma
> }
>
> if (info.target || info.status || info.size || flags &
> MAPINFO_TGT_TYPE__) {
> + if (!dmi.live_table) {
> + /*
> + * If this is device has a multipath uuid
> but no
> + * table, flag it, so multipath can clean it
> up
> + */
> + if (flags & MAPINFO_CHECK_UUID &&
> + !dmi.inactive_table) {
> + condlog(2, "%s: multipath map %s has
> no table",
> + fname__, map_id);
> + return DMP_BAD_DEV;
What about the case when there's an inactive_table? AFAIU that means
that a resume operation after a table (re)load failed or was
interrupted, or that the program that (re)loaded the table (multipathd,
probably) died before it could resume the table.
In this case we'd fall through the the "map has no targets" case, but
shouldn't we also treat it as DMP_BAD_DEV?
Martin
