From: "Bryn M. Reeves" <bmr@redhat.com>
To: dm-devel@redhat.com
Subject: multipath -f/-F exit status
Date: Fri, 12 Dec 2008 15:30:27 +0000 [thread overview]
Message-ID: <49428393.6040102@redhat.com> (raw)
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.
next reply other threads:[~2008-12-12 15:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-12 15:30 Bryn M. Reeves [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-12-13 11:59 multipath -f/-F exit status 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
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=49428393.6040102@redhat.com \
--to=bmr@redhat.com \
--cc=dm-devel@redhat.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.