Bug 1298932 - lvm_vg_is_* do not return correct values
Summary: lvm_vg_is_* do not return correct values
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.7
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Peter Rajnoha
QA Contact: cluster-qe@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2016-01-15 12:34 UTC by dfabian
Modified: 2016-05-11 01:20 UTC (History)
10 users (show)

Fixed In Version: lvm2-2.02.140-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-05-11 01:20:23 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0964 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2016-05-10 22:57:40 UTC

Description dfabian 2016-01-15 12:34:53 UTC
Description of problem:
The documentation in lvm2app.h specifies that lvm_vg_is_clustered() returns 1 if VG is clustered and 0 otherwise. However, the function returns 1024 if VG is clustered. This is because the macro vg_is_clustered in metadata-exported.h is set to

#define vg_is_clustered(vg) (vg_status((vg)) & CLUSTERED)

instead of

#define vg_is_clustered(vg) ((vg_status((vg)) & CLUSTERED) ? 1 : 0)

like in the case of for instance lv_is_locked

Other vg_is_* macros exhibit the similar issue.

The incorrect return value breaks the python wrapper as it does

rval = ( lvm_vg_is_clustered(self->vg) == 1) ? Py_True : Py_False;

which always returns Py_False regardless of the VG state.

How reproducible:

Steps to Reproduce:
Build and run thic C program
#include <lvm2app.h>
#include <stdio.h>

int main(int args, char**argv)
    lvm_t libh;
    vg_t vg = NULL;
    libh = lvm_init(NULL);
    vg = lvm_vg_open(libh, <clustered_vg_name>, "r", 0);
    printf("ret: %lu\n", lvm_vg_is_clustered(vg));
    return 0;

The program returns "ret: 1024".

Actual results:

Expected results:
lvm_vg_is_clustered() and others should return 1 if the specific flag is set in the VG.

Additional info:

Comment 2 Peter Rajnoha 2016-01-15 13:15:30 UTC
Nice catch! We'll certainly fix this, thanks for the report.

Comment 6 Roman Bednář 2016-03-03 10:09:34 UTC
Verified as SanityOnly. No new issues observed during regression testing.

Comment 8 errata-xmlrpc 2016-05-11 01:20:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.