Mailinglist Archive: opensuse-bugs (4283 mails)

< Previous Next >
[Bug 1037309] [lvmlockd regression] lvmlockd always fails to behave in latest version 2.02.170
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Wed, 03 May 2017 09:53:43 +0000
  • Message-id: <>

--- Comment #5 from Tomáš Chvátal <tchvatal@xxxxxxxx> ---
(In reply to zhen ren from comment #4)

(In reply to Tomáš Chvátal from comment #3)
Hmm, it seems upstream is a bit funny there.

I will check the commits between the version 168 and 170.

You can compile separate lockd as we do but it won't be loaded.

You mean splitting lockd out from lvm2-clvm? Sorry, but what do you mean by
"it won't be loaded"?

We compile lockd as a separate package, but the main files are provided in

Those main files like vgcreate are compiled with LVMLOCKD_SUPPORT=0

If you check the .h file it states for the LVMLOCKD_SUPPORT undefined to
inline those functions (see 'static inline') on the declarations.

Yes, macro LVMLOCKD_SUPPORT should be "1" so that the real code can be
compiled in.

Unless I am mistaken this means for the compiler to actually put the code in
the binary rather than issue follow up call for the function later on.

Yes, the problem is, i think, why LVMLOCKD_SUPPORT is not "1"? I'm not
familiar with make-auto tools, but I will dig more.

It is correctly 0 for the vgcreate and others as per above.

Problem is that this header file is written in such a way that it breaks if you
try to overload the function later on to actually allow the loading of the full
proper lockd functions.

The detection like this should not be decided by the compilation flag but done
in runtime like in clvm...

Something like

And of course the header must not inline those functions in either case.

You are receiving this mail because:
You are on the CC list for the bug.
< Previous Next >