1
0
mirror of git://sourceware.org/git/lvm2.git synced 2025-07-03 00:58:59 +03:00

575 Commits

Author SHA1 Message Date
29a799961c cov: add checked variants for mda_is_ignored and rlocn_is_ignored
Introduce _mda_is_ignored() and _rlocn_is_ignored() wrapper functions
with warn_unused_result attribute to enforce return value checking.

This follows the established pattern used by dm_strncpy() and _dm_strncpy():
- Functions without underscore prefix can be used without checking return values
- Functions with underscore prefix must have their return values checked

The change improves static analysis coverage by ensuring that critical
metadata area and raw location ignored state checks are properly validated,
reducing the risk of unhandled error conditions in metadata processing.
2025-06-30 16:56:43 +02:00
b8b0fcfa10 cov: remove unused header 2025-04-01 15:37:36 +02:00
951fd6358b metadata: replace pv status WRONG_VG with pv bit field
Avoid any special meaning associated with the status field.
2025-03-06 10:52:50 -06:00
8efbffe086 lvmcache: unpair wrong PV devs and improve duplicate name warnings
After detecting that a VG has wrongly claimed a PV, unpair
the pv->dev setting.  This will cause the usual "missing PV"
message to appear for that VG.  Make this message, and some
others, clearer by using the VGID rather than the VG name
when there are multiple VGs with the same name.
2025-03-06 10:02:29 -06:00
cff93e4d5c lvmcache: fix check for no pvid 2025-03-05 16:03:42 -06:00
227d3ca507 lvmcache: add WRONG_VG PV status flag
_vg_read() calls lvmcache_update_vg_from_read() which detects
that the VG metadata is incorrectly claiming the PV.  Flag this
condition in the PV status as WRONG_VG.  Later, vg_read() can
simply check the WRONG_VG flag rather than repeating the same
PV/VG checks that were already done in lvmcache_update_vg_from_read.
2025-03-05 14:28:42 -06:00
cc843151b4 lvmcache: ignore incorrect PV claim from old metadata
Outdated VG metadata that appears when an old device is attached
to the system can result in PVs appearing to belong to the
old/wrong VG, and commands are allowed to use (corrupt) the PVs.

- vgcreate old /dev/sda /dev/sdb /dev/sdc
- offline /dev/sda
- vgreduce --removemissing old
- vgremove old
- vgcreate new /dev/sdb /dev/sdc
- online /dev/sda

When sda is reattached, sdb and sdc will appear to be
in VG old again.  An attempt to correct the problem,
e.g. with vgremove old or vgreduce old, would modify
sdb and sdc, removing them from the new VG.

To fix this, check that sdb and sdc contain metadata for
VG old before allowing VG old to claim ownership of them.
With the fix, sdb and sdc are not displayed as part of
VG old, and commands to change VG old will fail as long
as it references incorrect PVs.

To fix VG old (sda), remove the incorrect PVs from VG old
while limiting the command to see only the correct PVs:
vgreduce --removemissing --devices /dev/sda old
2025-03-05 14:16:46 -06:00
924221765e cleanup: match function prototype with definition
Match variable name in function definition with
its prototype. Pick the name which better fits
the usage.

No functional change.
2025-02-17 15:51:03 +01:00
39b7d1ba8f cleanup: typos in comments
Collection of typos in code comments.
Should have no runtime effect.
2024-08-30 16:51:15 +02:00
d1c6da2f66 cov: validate altdev list is not empty 2024-08-09 15:10:18 +02:00
f8aa073a8d Revert "dev-cache: move global variables into cmd struct"
This reverts commit 77be3250d9.
2024-07-08 15:32:41 -05:00
77be3250d9 dev-cache: move global variables into cmd struct
The cmd struct is now required in many more functions, and
it's added as a function arg for most direct dev-cache function
calls.  The cmd struct is added to struct device (dev->cmd) so
that it can be accessed in many other cases where dev-cache
functions are being called from places where getting the cmd
struct is too difficult.
2024-07-03 11:52:32 -05:00
bf60cb4da2 lvmlockd: avoid lockd_vg for local VGs
Previously, a command would call lockd_vg() for a local VG,
which would go to lvmlockd, which would send back ENOLS,
and the command would not care when it saw the VG was local.
The pointless back-and-forth to lvmlockd for local VGs can
be avoided by checking the VG lock_type in lvmcache (which
label_scan now saves there; this wasn't the case back when
the original lockd_vg logic was added.)  If the lock_type
saved during label_scan indicates a local VG, then the
lockd_vg step is skipped.
2024-06-27 13:29:03 -05:00
cc344c3e69 dev_cache: replace dm_hash with radix_tree
For large device sets our dm_hash can produce larger amounf of mapping
collision and we would need to further increase our has size.

So instead use the radix_tree code which is immune agains growing size
of devices and uses memory more effiecently to store all the paths.
2024-06-21 11:28:54 +02:00
21b683614c lvmcache: stop saving duplicate pvs info between scans
In the past it was common for a single command to run
multiple lvmcache_label_scan, and this code was a way
to make each call select the same duplicate pvs.  Now
commands run a single lvmcache_label_scan, so this is
not needed.
2024-04-26 14:13:46 -05:00
f59ec61fa7 lvmcache: fix memleaks on list removal
Free members released from the list.
2024-04-15 12:58:27 +02:00
c78970c0d0 lvmcache: free list of add_cache_devs 2024-04-03 15:59:25 -05:00
fb80ed3143 cleanup: remove lvmcache_has_bad_metadata 2024-03-30 00:17:39 +01:00
622284740a pvs, pvscan: new option -A to show PVs outside the devices file
pvs -A|--allpvs
	Show PVs that would otherwise be excluded by the devices file.

pvscan -A|--allpvs
	Show PVs that would otherwise be excluded by the devices file.
	For those devices that are included by the devices file,
	their device ID is displayed in place of the usual "lvm2"
	format and size.

(pvs -a|--all is unchanged, and shows devices not formatted as PVs.)
2023-11-16 08:45:46 -06:00
37773c1055 lvmdevices: new output and options for check and update
- add new comparison between old and new entries, and use this
  as the basis for new dedicated output for check and update
- add new --refresh option to search for missing PVIDs on all
  devices, and possibly update the device ID
- internally, only use the term "refresh" for cases where a
  new device ID may be found and assigned for a missing PVID
2023-11-02 11:46:31 -05:00
a5628cf782 device_id: improve validate debug messages
Make the device_ids_validate messages consistent.

Consistently use "noupdate" and "update_needed" args.
2023-11-02 11:46:31 -05:00
1901a47df1 device_id: fix conditions for device_ids_refresh
Fix commit 847f1dd99c
"device_id: rewrite validation of devname entries"

which began calling device_ids_refresh() in cases where it
was unnecessary, leading to extra PV searches and warnings.
Specifically, a command like "lvs <vg>" would use the hints
file to scan only devices for the named VG.  This means that
scanning other PVs would be skipped, and device IDs of those
PVs could not be validated because there are no PVID values
to verify.  This missing info would cause messages about
the missing info, and would cause device_ids_refresh to
search for the PVs that had been intentionally skipped.
2023-10-05 15:33:55 -05:00
88aa285a79 devices: refresh device ids if the system changes
If the system changes, locate PVs that appear on different devices,
and update the device IDs in the devices file.  A system change is
detected by saving the DMI product_uuid or hostname in the devices
file, and comparing it to the current system value.  If a root PV
is restored or copied to a new system with different devices, then
the product_uuid or hostname should change, and trigger lvm to
locate PVIDs from system.devices on new devices.
2023-09-27 15:22:11 -05:00
670d982568 debug: drop stack from regular path 2023-09-03 22:03:33 +02:00
c451d7925d cleanup: correcting some log_print
Correcting to log_print_unless_silent(),
so -qq can do some work.
2023-05-06 20:38:49 +02:00
6d262eaf64 lvmcache: fix valgrind error when dropping md duplicate
When lvmcache info is dropped because it's an md component,
then the lvmcache vginfo can also be dropped, but the list
iterator was still using the list head in vginfo, so break
from the loop earlier to avoid it.
2023-04-25 14:46:36 -05:00
e3534d0f68 lvm: fix typos
Patch aec5e573af was fixing some
of typos only in generated file, but they need to be fixed in
the source files.
2023-02-10 17:50:27 +01:00
f80273a107 lvmcache: fix strncpy len for wwid 2022-12-01 10:03:06 -06:00
c98617c593 devices: factor common list functions
which were duplicated in various places
2022-11-07 11:38:46 -06:00
761b922178 device_id: handle duplicate serial numbers
Handle multiple devices using the same serial number as
their device id.  After matching devices to devices file
entries, if there is a discrepency between the ondisk PVID
and the devices file PVID, then rematch devices to
devices file entries using PVID, looking at all disks
on the system with the same serial number.
2022-11-07 08:56:02 -06:00
c21783d492 covscan: free wwid strings in lvmcache 2022-09-21 12:15:13 -05:00
99ce09ae77 apply multipath_component_detection=0 to duplicate PV handling
multipath_component_detection=0 has always applied to the filter-based
component detection.  Also apply this setting to the duplicate-PV
handling which also eliminates multipath components (based on duplicate
PVs having the same wwid.)
2022-07-25 13:50:43 -05:00
92b4fcf57f exit with error when --devicesfile name doesn't exist 2022-07-06 10:10:58 -05:00
18f451e09e handle duplicate vgids
The approach to duplicate VGIDs has been that it is not possible
or not allowed, so the behavior has been undefined.  The actual
result was unpredictable and/or broken, and generally unhelpful.

Improve this by recognizing the problem, displaying the VGs,
and printing a warning to fix the problem.  Beyond this,
using VGs with duplicate VGIDs remains undefined, but should
work well enough to correct the problem with vgchange -u.

It's possible to create this condition without too much difficulty
by cloning PVs, followed by an incomplete attempt at making the two
VGs unique (vgrename and pvchange -u, but missing vgchange -u.)
2022-01-13 10:01:24 -06:00
cb798ee1c1 lvmcache: remove lvmcache_update_vg_from_write
After a vg_write, this function was used to attempt to
make lvmcache data match the new state written to disk.
It was not updated correctly in a many or most cases,
and the resulting lvmcache is not actually used after
vg_write, making the update unnecessary.
2022-01-13 10:01:16 -06:00
7502f78678 Revert "handle duplicate vgids"
This reverts commit bd2baeaaa6.

This commit broke vgrename because vgrename relies on old bugs
in lvmcache_update_vg_from_write and lvmcache_update_vgname
which need to be fixed first.
2022-01-11 16:04:51 -06:00
bd2baeaaa6 handle duplicate vgids
The approach to duplicate VGIDs has been that it is not possible
or not allowed, so the behavior has been undefined.  The actual
result was unpredictable and/or broken, and generally unhelpful.

Improve this by recognizing the problem, displaying the VGs,
and printing a warning to fix the problem.  Beyond this,
using VGs with duplicate VGIDs remains undefined, but should
work well enough to correct the problem with vgchange -u.

It's possible to create this condition without too much difficulty
by cloning PVs, followed by an incomplete attempt at making the two
VGs unique (vgrename and pvchange -u, but missing vgchange -u.)
2022-01-06 10:15:16 -06:00
01bf8e1747 devices: exclude md components when duplicate pvs are seen
Improve handling of md components that get through the
filter, like the previous improvement for multipath.
If md components get through the filter and trigger
duplicate PV code, then eliminate any devs entirely
that are not an md device.
2021-11-22 15:10:43 -06:00
212b1fc529 devices: exclude multipath components based on matching wwid
If multipath component devices get through the filter and
cause lvm to see duplicate PVs, then check the wwid of the
devs and drop the component devices as if they had been
filtered.  If a dm mpath device was found among the duplicates
then use that as the PV, otherwise do not use any of the
components as the PV.

"duplicate PVs" associated with multipath configs will no
longer stop commands from working.
2021-11-18 17:41:00 -06:00
62533ae3fa vgchange -aay: optimize device list using pvs_online files
Port another optimization from pvscan -aay to vgchange -aay:
  "pvscan: only add device args to dev cache"

This optimization avoids doing a full dev_cache_scan, and
instead populates dev-cache with only the devices in the
VG being activated.

This involves shifting the use of pvs_online files from
the hints interface up to the higher level label_scan
interface.  This specialized label_scan is structured
around creating a list of devices from the pvs_online
files.  Previously, a list of all devices was created
first, and then reduced based on the pvs_online files.
The initial step of listing all devices was slow when
thousands of devices are present on the system.

This optimization extends the previous optimization that
used pvs_online files to limit the devices that were
actually scanned (i.e. reading to identify the device):
  "vgchange -aay: optimize device scan using pvs_online files"
2021-11-05 12:19:35 -05:00
c38473548e fix segfault handling duplicate PVs
cmd arg was missing when switching to use an alternative
duplicate dev.
2021-10-14 14:02:59 -05:00
e88163ceac fix lvmcache_add log_debug pvid
from previous cleanup
2021-10-13 17:30:21 -05:00
79e65a3596 cleanup: all lvmcache_add users pass char with 0
No local copy needed, both users submit zero-end string as pv/vgid.
2021-10-06 15:43:31 +02:00
939b4bc587 handle bad metadata text in vg_read path
Corrupt metadata text (with good mda header) was being handled
in the label_scan phase, but not in the vg_read phase.  This
was sufficient because metadata areas would always be read and
checksummed during label_scan (metadata parsing was skipped
previously as an optimization.)

This changed with the optimization in
commit 61a6f9905e
"metadata: optimize reading metadata copies in scan"

Now, some metadata areas will not be read and checksummed
at all during the label_scan phase, only during the vg_read
phase.  This means that bad metadata text may first be detected
in the vg_read phase.  So, add equivalent bad metadata handling
to the vg_read path to match the label_scan path.
2021-09-28 15:17:43 -05:00
130993bab1 lvmcache: follow pv_id/pvid naming convention
name the variable pv_id_arg to follow the convention:
. "pvid" variable is null-terminated string
. "pv_id" variable is non-null-terminated struct
2021-09-20 09:35:47 -05:00
133686ebc7 gcc: avoid name colision with function pv_id() from metadata.h 2021-09-20 16:12:10 +02:00
96b777167c cov: clean up pvid and vgid usage
pvid and vgid are sometimes a null-terminated string, and
other times a 'struct id', and the two types were often
cast between each other.  When a struct id was cast to a char
pointer, the resulting string would not necessarily be null
terminated.  Casting a null-terminated string id to a
struct id is fine, but is still avoided when possible.

A struct id is:  int8_t uuid[ID_LEN]
A string id is:  char pvid[ID_LEN + 1]

A convention is introduced to help distinguish them:

- variables and struct fields named "pvid" or "vgid"
  should be null-terminated strings.

- variables and struct fields named "pv_id" or "vg_id"
  should be struct id's.

- examples:
  char pvid[ID_LEN + 1];
  char vgid[ID_LEN + 1];
  struct id pv_id;
  struct id vg_id;

Function names also attempt to follow this convention.

Avoid casting between the two types as much as possible,
with limited exceptions when known to be safe and clearly
commented.

Avoid using variations of strcpy and strcmp, and instead
use memcpy/memcmp with ID_LEN (with similar limited
exceptions possible.)
2021-08-16 11:31:15 -05:00
9048565093 devices: rework libudev usage
related to config settings:
  obtain_device_info_from_udev (controls if lvm gets
    a list of devices from readdir /dev or from libudev)
  external_device_info_source (controls if lvm asks
    libudev for device information)

. Make the obtain_device_list_from_udev setting
  affect only the choice of readdir /dev vs libudev.
  The setting no longer controls if udev is used for
  device type checks.

. Change obtain_device_list_from_udev default to 0.
  This helps avoid boot timeouts due to slow libudev
  queries, avoids reported failures from
  udev_enumerate_scan_devices, and avoids delays from
  "device not initialized in udev database" errors.
  Even without errors, for a system booting with 1024 PVs,
  lvm2-pvscan times improve from about 100 sec to 15 sec,
  and the pvscan command from about 64 sec to about 4 sec.

. For external_device_info_source="none", remove all
  libudev device info queries, and use only lvm
  native device info.

. For external_device_info_source="udev", first check
  lvm native device info, then check libudev info.

. Remove sleep/retry loop when attempting libudev
  queries for device info.  udev info will simply
  be skipped if it's not immediately available.

. Only set up a libdev connection if it will be used by
  obtain_device_list_from_udev/external_device_info_source.

. For native multipath component detection, use
  /etc/multipath/wwids.  If a device has a wwid
  matching an entry in the wwids file, then it's
  considered a multipath component.  This is
  necessary to natively detect multipath
  components when the mpath device is not set up.
2021-07-13 11:11:23 -05:00
66daedc6d2 skip indexing devices used by LVs in more commands
expands commit d5a06f9a7d
  "pvscan: skip indexing devices used by LVs"

The dev cache index is expensive and slow, so limit it
to commands that are used to observe the state of lvm.
The index is only used to print warnings about incorrect
device use by active LVs, e.g. if an LV is using a
multipath component device instead of the multipath
device.  Commands that continue to use the index and
print the warnings:

  fullreport, lvmdiskscan, vgs, lvs, pvs,
  vgdisplay, lvdisplay, pvdisplay,
  vgscan, lvscan, pvscan (excluding --cache)

A couple other commands were borrowing the DEV_USED_FOR_LV
flag to just check if a device was actively in use by LVs.
These are converted to the new dev_is_used_by_active_lv().
2021-07-09 13:59:31 -05:00
71cb54d92f coverity cleanups 2021-06-16 13:42:51 -05:00