tree d8d4df84da2a36baf42d2d24b2036d1c38fedb7f
parent 0ac10bb23a9e356b87ead9e1304a6482f6761b9b
author Peter Rajnoha <prajnoha@redhat.com> 1442331482 +0200
committer Peter Rajnoha <prajnoha@redhat.com> 1442333252 +0200

format-text: label: fix missing dev assignment for struct label in _text_pv_write

When using lvm shell, some structures which are cached in memory may be
reused. This happens for the struct label (a part of lvmcache_info
structure) when lvmetad is used in which case the PV scan is not
done that would normally overwrite these label structures in memory
and making them up-to-date.

This is all consequence of the fact that struct lvmcache_info and
struct label are not always assigned in the same part of the code.
For example, if lvmetad *is not* used, parts of the struct label are
reassigned in label_read fn while struct lvmcache_info is created
elsewhere. No part of the code reused struct label (and its "dev"
field) before calling label_read fn. That's why the real bug is
hidden when using lvm shell without lvmetad.

However, with lvmetad and lvm shell, the situation is a bit different.
The label_read fn is not called if lvmetad *is* used, hence the
struct label may have ended up not initialized properly.

There was missing assignment for the dev field in struct label
in _text_pv_write fn which caused this problem to appear in
lvm shell with lvmetad, for example:

Before this patch:

lvm> pvcreate /dev/sda
  Physical volume "/dev/sda" successfully created
lvm> pvs /dev/sda
  PV             VG     Fmt  Attr PSize   PFree
  unknown device        lvm2 ---  128.00m 128.00m

With this patch applied:

lvm> pvcreate /dev/sda
  Physical volume "/dev/sda" successfully created
lvm> pvs /dev/sda
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sda        lvm2 ---  128.00m 128.00m

Also, this problem had not appeared before changes introduced
by commits e1a63905d14cc73352b905c70cb4084b7e521e33 through
3a6f91d7139119bea664050a957cbc21490398bc which, among other
things, added proper label field type reporting. Before, label
reporting was the same as using struct physical_volume which
has its own dev field assigned and so this problem was not exposed.