Bug 1330417

Summary: pmap -x shows all lines twice
Product: Red Hat Enterprise Linux 7 Reporter: Branislav Náter <bnater>
Component: procps-ngAssignee: Jan Rybar <jrybar>
Status: CLOSED ERRATA QA Contact: David Jež <djez>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.3CC: bnater, isenfeld, jbastian, jcm, lmiksik, ovasik, qe-baseos-apps, yselkowi
Target Milestone: rcKeywords: Patch, Regression
Target Release: 7.4   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: procps-ng-3.3.10-12.el7 Doc Type: Bug Fix
Doc Text:
Cause: With kernel-4.x a new field SwapPss was added into /proc/PID/smaps file. Consequence: pmap program unintentionally recognized this new SwapPss field as same as common Swap field and printed the same values for SwapPss as for Swap field. Fix: pmap was extended with recognition the difference between Swap and SwapPss field in /proc/PID/smaps file. Result: pmap now prints out only values for Swap field as expected and leaves out doubled values for SwapPss field. The lines now do not appear doubled in the program's output.
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-01 18:02:15 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: 1374061    
Bug Blocks: 1380361, 1381083, 1393867    
Attachments:
Description Flags
Patch for rhel-7.3
none
Patch applied to RHEL-7.4 none

Description Branislav Náter 2016-04-26 08:10:33 UTC
Description of problem:
On aarch64, pmap -x $$ shows all lines twice, second occurrence with 0 values. pmap $$ (no extended output) output looks correct

Version-Release number of selected component (if applicable):
procps-ng-3.3.10-5.el7_2

How reproducible:
always

Steps to Reproduce:
1. pmap -x $$

Actual results:
15106:   -bash
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     896     832       0 r-x-- bash
0000000000400000       0       0       0 r-x-- bash <-----------
00000000004e0000      64      64      64 r---- bash
00000000004e0000       0       0       0 r---- bash <-----------
00000000004f0000      64      64      64 rw--- bash
00000000004f0000       0       0       0 rw--- bash <----------
0000000005060000    1536    1536    1536 rw---   [ anon ]
0000000005060000       0       0       0 rw---   [ anon ]
000003ff76b00000      64      64      64 rw---   [ anon ]
000003ff76b00000       0       0       0 rw---   [ anon ]
000003ff76b10000      64      64       0 r-x-- libnss_files-2.17.so
000003ff76b10000       0       0       0 r-x-- libnss_files-2.17.so
<snip>

Expected results:
15106:   -bash
Address           Kbytes     RSS   Dirty Mode  Mapping
0000000000400000     896     832       0 r-x-- bash
00000000004e0000      64      64      64 r---- bash
00000000004f0000      64      64      64 rw--- bash
0000000005060000    1536    1536    1536 rw---   [ anon ]
000003ff76b00000      64      64      64 rw---   [ anon ]
000003ff76b10000      64      64       0 r-x-- libnss_files-2.17.so
<snip>

Comment 1 Ondrej Vasik 2016-04-26 15:08:48 UTC
Not reproducible on Intel. Adding yselkowi to CC - as he is the best aarch64-foo person I'm aware of.

Comment 2 Yaakov Selkowitz 2016-04-26 17:12:22 UTC
Thanks for bringing this to my attention.  I just tried this on both a Mustang and a Seattle and I couldn't reproduce it either.

Branislav, on what hardware and with which kernel and firmware are you seeing this?

Comment 4 Yaakov Selkowitz 2016-04-27 08:41:46 UTC
This can also be reproduced on F23 x86_64 with a 4.4 kernel.  Therefore, I believe this is not actually aarch64 specific, but rather due to a change in /proc/PID/smaps sometime between 4.2 and 4.4.  I will continue to investigate.

Comment 5 Jan Rybar 2016-06-27 15:27:54 UTC
Reproducible on Fedora 23 x86_64, but not on RHEL7.3 on VM. Will be investigated.

Comment 6 Lukáš Nykrýn 2016-06-29 12:56:51 UTC
devel_ack for 7.3

Comment 7 Yaakov Selkowitz 2016-09-07 19:16:46 UTC
This appears to be related:

https://bugzilla.opensuse.org/show_bug.cgi?id=962275

The patch mentioned there does two things: 1) fixes handling of new maps fields, which we need with kernel 4.4+ (Fedora and RHELSA), 2) changes the argument defaults, which we do not want.  Testing a revised patch now.

Comment 8 Yaakov Selkowitz 2016-09-07 19:43:46 UTC
Created attachment 1198826 [details]
Patch for rhel-7.3

This takes OpenSUSE's patch for 3.3.11, backports it to 3.3.10 and removes 
the changes they made to the default arguments.  Please double-check that 
there aren't any other of their customizations that we do not want.

I tested this on a seattle with the latest snapshot -- which by itself is
affected -- and this fixes it.  It also does not appear to break anything 
on x86_64 (tested on a system with 7.3 HTB).

Successful scratch build:

https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=11715265

Comment 18 Jan Rybar 2017-02-21 08:04:12 UTC
Created attachment 1256000 [details]
Patch applied to RHEL-7.4

Comment 22 errata-xmlrpc 2017-08-01 18:02:15 UTC
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.

https://access.redhat.com/errata/RHBA-2017:1898