* multipath -f/-F exit status
@ 2008-12-12 15:30 Bryn M. Reeves
0 siblings, 0 replies; 5+ messages in thread
From: Bryn M. Reeves @ 2008-12-12 15:30 UTC (permalink / raw)
To: dm-devel
Hi Folks,
Older versions of multipath-tools would always exit with status 0
(success) when flushing multipath device maps (-f/-F). This was never
guaranteed but happened because the "r" local in multipath/main.c was
used uninitialised in these code paths (by chance, it always lands on a
freshly zeroed stack page, so although undefined the behaviour was
pretty reliable).
This was changed by commit 8497928514aa3df6d46f24d8d9b70b086e9fcfbd:
commit 8497928514aa3df6d46f24d8d9b70b086e9fcfbd
Author: Christophe Varoqui <root@xa-s05.(none)>
Date: Mon Mar 13 14:55:16 2006 +0100
[build] minor compilation issues
SuSE checker found some minor issues:
- refwwid in libmultipath/configure.c:get_refwwid() might be used
uninitialized. As dev_type is a simple 'int' there is nothing which
prevents the unsuspecting user to call it with an unhandled value.
We shoud rather use an enum and set refwwid to NULL to be on the
safe side.
- attr in libmultipath/discovery.c:devt2devname() might be used
uninitialized. Quite unlikely, but might happen in principle.
So better have it initialized.
- r in multipath/main.c:main() might be used uninitialized.
True. So have it initialized.
This causes -f/-F in more recent versions of the tools to always exit
with status 1 (failure) which does not seem correct.
I think the following would be an improvement on the current behaviour:
multipath -f <map>
------------------
-f flush a multipath device map specified as parameter, if unused
Exit Status
0 The map existed and was successfully flushed
1 The map did not exist or could not be flushed
multipath -F
------------
-F flush all unused multipath device maps
Exit status
0 At least one unused multipath device map was flushed
1 No unused maps were found or no maps could be flushed
The alternative for -F seems to be to return 0 if all unused maps were
flushed and 1 if there were unused maps that could not be flushed. This
doesn't seem like a very likely occurrence, but maybe it should be
handled separately?
Regards,
Bryn.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: multipath -f/-F exit status
2008-12-17 23:05 ` Christophe Varoqui
@ 2008-12-18 16:41 ` Bryn M. Reeves
0 siblings, 0 replies; 5+ messages in thread
From: Bryn M. Reeves @ 2008-12-18 16:41 UTC (permalink / raw)
To: Christophe Varoqui; +Cc: dm-devel
Christophe Varoqui wrote:
> The following patch will appear soon at k.org
> It should do what you expect.
Great - thanks! I've had the user who reported this test with an
identical change and they are happy with this behaviour.
Cheers,
Bryn.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: multipath -f/-F exit status
2008-12-13 11:59 Christophe Varoqui
2008-12-15 17:35 ` Bryn M. Reeves
@ 2008-12-17 23:05 ` Christophe Varoqui
2008-12-18 16:41 ` Bryn M. Reeves
1 sibling, 1 reply; 5+ messages in thread
From: Christophe Varoqui @ 2008-12-17 23:05 UTC (permalink / raw)
To: bmr; +Cc: dm-devel
The following patch will appear soon at k.org
It should do what you expect.
Thanks for the comment,
cvaroqui
diff --git a/libmultipath/devmapper.c b/libmultipath/devmapper.c
index bcbeb28..6b289cf 100644
--- a/libmultipath/devmapper.c
+++ b/libmultipath/devmapper.c
@@ -568,7 +568,7 @@ dm_flush_maps (void)
goto out;
do {
- r += dm_flush_map(names->name);
+ r |= dm_flush_map(names->name);
next = names->next;
names = (void *) names + next;
} while (next);
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: multipath -f/-F exit status
2008-12-13 11:59 Christophe Varoqui
@ 2008-12-15 17:35 ` Bryn M. Reeves
2008-12-17 23:05 ` Christophe Varoqui
1 sibling, 0 replies; 5+ messages in thread
From: Bryn M. Reeves @ 2008-12-15 17:35 UTC (permalink / raw)
To: device-mapper development
Christophe Varoqui wrote:
>> Hi Folks,
>>
>> Older versions of multipath-tools would always exit with status 0
>> (success) when flushing multipath device maps (-f/-F). This was never
>> guaranteed but happened because the "r" local in multipath/main.c was
>> used uninitialised in these code paths (by chance, it always lands on
>> a freshly zeroed stack page, so although undefined the behaviour was
>> pretty reliable).
>>
>> This was changed by commit 8497928514aa3df6d46f24d8d9b70b086e9fcfbd:
>>
> Then by a9a6c71592d4e2271a38c3d334bee7cbce963cff.
>
> Does the upstream version works as you expect in this regard ?
Sorry - not sure how I missed that last week.
>> The alternative for -F seems to be to return 0 if all unused maps were
>> flushed and 1 if there were unused maps that could not be flushed.
>> This doesn't seem like a very likely occurrence, but maybe it should
>> be handled separately?
>>
> I guess the current implementation return r as the number failures.
It does, which seems a slightly strange thing to return - I don't see
how it's useful as it's actually the number of device-mapper maps that
we couldn't flush (sum of returns from dm_flush_map), i.e. the total
number of maps that either weren't multipath, weren't unused etc :)
This will cause problems on systems that have 256 such maps since the
exit status is truncated to 8-bits and we would falsely reported the
status as zero.
It seems more useful to return an overall success/failure indication for
these commands and would be more in-keeping with other similar tools and
POSIX.
Regards,
Bryn.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: multipath -f/-F exit status
@ 2008-12-13 11:59 Christophe Varoqui
2008-12-15 17:35 ` Bryn M. Reeves
2008-12-17 23:05 ` Christophe Varoqui
0 siblings, 2 replies; 5+ messages in thread
From: Christophe Varoqui @ 2008-12-13 11:59 UTC (permalink / raw)
To: bmr; +Cc: dm-devel
> Hi Folks,
>
> Older versions of multipath-tools would always exit with status 0
> (success) when flushing multipath device maps (-f/-F). This was never
> guaranteed but happened because the "r" local in multipath/main.c was
> used uninitialised in these code paths (by chance, it always lands on
> a freshly zeroed stack page, so although undefined the behaviour was
> pretty reliable).
>
> This was changed by commit 8497928514aa3df6d46f24d8d9b70b086e9fcfbd:
>
Then by a9a6c71592d4e2271a38c3d334bee7cbce963cff.
Does the upstream version works as you expect in this regard ?
> multipath -F
> ------------
>
> -F flush all unused multipath device maps
>
> Exit status
> 0 At least one unused multipath device map was flushed
> 1 No unused maps were found or no maps could be flushed
>
> The alternative for -F seems to be to return 0 if all unused maps were
> flushed and 1 if there were unused maps that could not be flushed.
> This doesn't seem like a very likely occurrence, but maybe it should
> be handled separately?
>
I guess the current implementation return r as the number failures.
Regards,
cvaroqui
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-12-18 16:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-12-12 15:30 multipath -f/-F exit status Bryn M. Reeves
2008-12-13 11:59 Christophe Varoqui
2008-12-15 17:35 ` Bryn M. Reeves
2008-12-17 23:05 ` Christophe Varoqui
2008-12-18 16:41 ` Bryn M. Reeves
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.