Bug 989347
| Summary: | lvextend segfaults in _alloc_parallel_area when trying to extend 3-way striped logical volume | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Brad Hubbard <bhubbard> |
| Component: | lvm2 | Assignee: | Alasdair Kergon <agk> |
| Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> |
| Severity: | urgent | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.4 | CC: | agk, bhubbard, cmarthal, dwysocha, heinzm, jbrassow, jkurik, jmagrini, jruemker, msnitzer, nperic, prajnoha, prockai, thornber, zkabelac |
| Target Milestone: | rc | Keywords: | ZStream |
| Target Release: | 6.5 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | lvm2-2.02.100-1.el6 | Doc Type: | Bug Fix |
| Doc Text: |
Due to an error in the LVM allocation code, lvm2 attempted free space allocation contiguous to an existing striped space. When trying to extend a 3-way striped logical volume using the lvextend command, the lvm2 utility terminated unexpectedly with a segmentation fault. With this update, the behavior of LVM has been modified, and lvextend now completes the extension without a segmentation fault.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-11-21 23:26:10 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1016082, 1016083 | ||
|
Description
Brad Hubbard
2013-07-29 06:31:11 UTC
1155 pva = alloc_state->areas[s + ix_log_skip].pva;
1156 if (ah->alloc_and_split_meta) {
(gdb)
1157 /*
1158 * The metadata area goes at the front of the allocated
1159 * space for now, but could easily go at the end (or
1160 * middle!).
1161 *
1162 * Even though we split these two from the same
1163 * allocation, we store the images at the beginning
1164 * of the areas array and the metadata at the end.
1165 */
1166 s += ah->area_count + ah->parity_count;
(gdb)
1167 aa[s].pv = pva->map->pv;
1168 aa[s].pe = pva->start;
1169 aa[s].len = ah->log_len;
1170
1171 log_debug("Allocating parallel metadata area %" PRIu32
1172 " on %s start PE %" PRIu32
1173 " length %" PRIu32 ".",
1174 (s - (ah->area_count + ah->parity_count)),
1175 pv_dev_name(aa[s].pv), aa[s].pe,
1176 ah->log_len);
(gdb)
1177
1178 consume_pv_area(pva, ah->log_len);
1179 dm_list_add(&ah->alloced_areas[s], &aa[s].list);
1180 s -= ah->area_count + ah->parity_count;
1181 }
1182 aa[s].len = (ah->alloc_and_split_meta) ? len - ah->log_len : len;
1183 /* Skip empty allocations */
1184 if (!aa[s].len)
1185 continue;
1186
(gdb)
1187 aa[s].pv = pva->map->pv;
(gdb) p s
$1 = 0
(gdb) p ix_log_skip
$2 = 0
(gdb) p alloc_state->areas[s + ix_log_skip].pva
$3 = (struct pv_area *) 0x0
I'm attaching logs collected with the following command.
# lvextend -vvvv -i1 -l+100%FREE vg1/lvol0 &>/tmp/lvextend.out
NOTE: this log is not from the same run that produced the core and not even the same system. If matching core file and logs are required let me know and we will provide them.
Reproduced with upstream code. There is an existing 3-striped allocation. The code is being asked to extend this with just 1 stripe. The allocation code is being supplied with the preceding 3 locations of the existing stripes so it can attempt 'contiguous' allocation of each those stripes if possible, but then it is only being asked to find 1 stripe. It is preparing 3 'slots' to fill with extents. It finds space contiguous to the 2nd existing stripe, so it puts it into the 2nd slot, assuming both the 1st and 3rd would be filled subsequently, but because it only needs 1 stripe it stops searching at that point. Then it unexpectedly finds the 1st slot NULL and crashes. The bug is that it should not have been asked to attempt allocation contiguous to existing striped space when extending with a different number of stripes. Upstream fix: https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=b6bfddcd0a830d0c9312bc3ab906cb3d1b7a6dd9 To test: create and extend LVs, varying the numbers of stripes. This bug could be hit if the extension needed a smaller number of stripes than the original. (If a larger number is needed, there is a different bug.) If the number of stripes varies, the new code makes no attempt to allocate contiguously or clinging (either with or without tags) to the already-allocated extents. (If more than one round of allocation is needed, later rounds do still try to cling to the layout from earlier rounds.) lvextend completes the extension without segfaulting tested with lvm2-2.02.100-4.el6.x86_64 kernel-2.6.32-421.el6.x86_64 There is a bug with allocation when using -l100%FREE though, will open another BZ for that specific case. Marking this one as VERIFIED. 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. http://rhn.redhat.com/errata/RHBA-2013-1704.html |