Bug 1402589

Summary: lvs cache_policy shows corrupted characters when large number of cached lvs are listed
Product: Red Hat Enterprise Linux 7 Reporter: Dustin Black <dblack>
Component: lvm2Assignee: Peter Rajnoha <prajnoha>
lvm2 sub component: Command-line tools QA Contact: cluster-qe <cluster-qe>
Status: CLOSED NEXTRELEASE Docs Contact:
Severity: low    
Priority: unspecified CC: agk, heinzm, jbrassow, msnitzer, prajnoha, prockai, thornber, zkabelac
Version: 7.2   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-27 11:14:23 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:

Description Dustin Black 2016-12-07 22:10:26 UTC
Description of problem:
Running the `lvs` command with many fields including -o cache_policy and passing a significant number of VGs with cached LVs to the command results in corrupted output in the 'Cache Policy' column.

Version-Release number of selected component (if applicable):
# rpm -qa |grep lvm2
lvm2-2.02.130-5.el7_2.5.x86_64
lvm2-libs-2.02.130-5.el7_2.5.x86_64


How reproducible:
Consistently


Steps to Reproduce:
1.Create more than 5 cached LVs
2.Run `lvs -a -o name,vg_name,size,pool_lv,devices,cachemode,cache_policy,cache_settings,chunksize vg{a..f}` 

Actual results:
Most fields in the 'Cache Policy' column show corrupted characters.


Expected results:
All 'Cache Policy' fields should correctly show the current policy.


Additional info:
Appears to be some kind of buffer overflow. The persistence of the issue is dependent on the number of fields displayed in the `lvs` output. For me with the command above,listing the output from 5 VGs works, but 6 VGs shows the corrupted characters. If I reduce the number of fields, 6 VGs may work and 7 may fail.

Comment 2 Jonathan Earl Brassow 2017-03-08 23:27:27 UTC
Could you please show the output?  Also, RHEL7.3 is out, could you test with that please?

Comment 3 Peter Rajnoha 2017-04-27 11:14:23 UTC
I think this is already fixed with

  https://sourceware.org/git/?p=lvm2.git;a=commit;h=a83d611a86e6da31f255d5d87adf14cb3d62a05a

The fix appeared in lvm2 v2.02.140. It was a regression since lvm2 v2.02.126.
I checked the lvm2-2.02.130-5.el7_2.5.x86_64 with valgrind and I hit the problems for which this patch was aimed for - that patch is not included in 7.2.z yet (not sure if we want to backport that or not).

It should fixed in 7.3 and higher releases.

Comment 4 Peter Rajnoha 2017-04-27 11:16:15 UTC
With valgrind, this problem is exposed as:

#valgrind lvs -a -o name,vg_name,size,pool_lv,devices,cachemode,cache_policy,cache_settings,chunksize
...
==10689== Invalid read of size 1
==10689==    at 0x4C30B5B: strnlen (vg_replace_strmem.c:421)
==10689==    by 0x5B96AA4: vfprintf (vfprintf.c:1637)
==10689==    by 0x5BC0488: vsnprintf (vsnprintf.c:114)
==10689==    by 0x54CFB23: dm_snprintf (libdm-string.c:129)
==10689==    by 0x54C5E8C: _output_field (libdm-report.c:4244)
==10689==    by 0x54C684E: _output_as_columns (libdm-report.c:4390)
==10689==    by 0x54C6B3A: dm_report_output (libdm-report.c:4434)
==10689==    by 0x15CE0C: _report (reporter.c:934)
==10689==    by 0x15CF0A: lvs (reporter.c:953)
==10689==    by 0x14E560: lvm_run_command (lvmcmdline.c:1655)
==10689==    by 0x14FB49: lvm2_main (lvmcmdline.c:2121)
==10689==    by 0x172BEF: main (lvm.c:22)