Commit Graph

619 Commits

Author SHA1 Message Date
Qualys Security Advisory
0753b86931 0069-proc/readproc.c: Fix the unhex() function.
This function is unused (SIGNAL_STRING is defined by default, and if it
is not, procps does not compile -- for example, there is no "outbuf" in
help_pr_sig()) but fix it anyway. There are two bugs:

- it accepts non-hexadecimal characters (anything >= 0x30);

- "(c - (c>0x57) ? 0x57 : 0x30)" is always equal to 0x57.

---------------------------- adapted for newlib branch
. newlib doesn't use that 'unlikely' crap

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-09 21:35:19 +10:00
Qualys Security Advisory
1e48648b82 0051-proc/escape.c: Prevent buffer overflows in escape_command().
This solves several problems:

1/ outbuf[1] was written to, but not outbuf[0], which was left
uninitialized (well, SECURE_ESCAPE_ARGS() already fixes this, but do it
explicitly as well); we know it is safe to write one byte to outbuf,
because SECURE_ESCAPE_ARGS() guarantees it.

2/ If bytes was 1, the write to outbuf[1] was an off-by-one overflow.

3/ Do not call escape_str() with a 0 bufsize if bytes == overhead.

4/ Prevent various buffer overflows if bytes <= overhead.
2018-06-09 21:35:19 +10:00
Qualys Security Advisory
1eddce14c3 0050-proc/escape.c: Prevent integer overflows in escape_str_utf8().
Simply rearrange the old comparisons. The new comparisons are safe,
because we know from previous checks that:

1/ wlen > 0

2/ my_cells < *maxcells (also: my_cells >= 0 and *maxcells > 0)

3/ len > 1

4/ my_bytes+1 < bufsize (also: my_bytes >= 0 and bufsize > 0)
2018-06-09 21:35:19 +10:00
Qualys Security Advisory
8f49e98a3f 0049-proc/escape.c: Handle negative wcwidth() return value.
This should never happen, because wcwidth() is called only if iswprint()
returns nonzero. But belt-and-suspenders, and make it visually clear
(very important for the next patch).
2018-06-09 21:35:19 +10:00
Qualys Security Advisory
1ecf125d3f 0048-proc/escape.c: Make sure all escape*() arguments are safe.
The SECURE_ESCAPE_ARGS() macro solves several potential problems
(although we found no problematic calls to the escape*() functions in
procps's code-base, but had to thoroughly review every call; and this is
library code):

1/ off-by-one overflows if the size of the destination buffer is 0;

2/ buffer overflows if this size (or "maxroom") is negative;

3/ integer overflows (for example, "*maxcells+1");

4/ always null-terminate the destination buffer (unless its size is 0).

---------------------------- adapted for newlib branch
. the escape.c now has just a single exported function
. thus SECURE_ESCAPE_ARGS() is needed in only 2 places
. unlike that original patch, macro is executed 1 time
( not like 'escape_command' calling 'escape_strlist' )
( which might then call 'escape_str' multiple times! )

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-09 21:35:19 +10:00
Qualys Security Advisory
efae601c3c 0047-proc/whattime.c: Always initialize buf.
In the human_readable case; otherwise the strcat() that follows may
append bytes to the previous contents of buf.

Also, slightly enlarge buf, as it was a bit too tight.

Could also replace all sprintf()s with snprintf()s, but all the calls
here output a limited number of characters, so they should be safe.

---------------------------- adapted for newlib branch
. the source file is now proc/uptime.c
. function is now named 'procps_uptime_sprint()'
. new human readable function 'procps_uptime_sprint_short()'
. both were already initialized, so just raised size of 2 buffers

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-09 21:35:19 +10:00
Qualys Security Advisory
d1729bed6b 0042-proc/slab.h: Fix off-by-one overflow in sscanf().
In proc/slab.c, functions parse_slabinfo20() and parse_slabinfo11(),
sscanf() might overflow curr->name, because "String input conversions
store a terminating null byte ('\0') to mark the end of the input; the
maximum field width does not include this terminator."

Add one byte to name[] for this terminator.

---------------------------- adapted for newlib branch
. file is now proc/slabinfo.c (not .h)
. manifest constant renamed SLABINFO_NAME_LEN
. older parse_slabinfo11() function no longer present

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-09 21:35:19 +10:00
Qualys Security Advisory
69b67b6f6e 0040-proc/devname.c: Never write more than "chop" (part 2).
"chop" is the maximum offset where the null-byte should be written;
respect this even if about to write just one (non-null) character.
2018-06-09 21:35:19 +10:00
Qualys Security Advisory
0e365c8930 0039-proc/devname.c: Never write more than "chop" characters.
This should be guaranteed by "tmp[chop] = '\0';" and "if(!c) break;" but
this patch adds a very easy belt-and-suspenders check.
2018-06-09 21:35:19 +10:00
Qualys Security Advisory
a3111efa71 0038-proc/devname.c: Prevent off-by-one overflow in dev_to_tty(). 2018-06-09 21:35:19 +10:00
Qualys Security Advisory
170397d59c 0037-proc/devname.c: Use snprintf() in link_name().
Found no problematic use case at the moment, but better safe than sorry.
Also, return an error on snprintf() or readlink() truncation.
2018-06-09 21:35:19 +10:00
Jim Warner
b0908eec4b library: replace the troublesome '__BEGIN_DECLS' macro
When 'newlib' was introduced, in the commit referenced
below, the use of that glibc '__BEGIN_DECLS' macro was
standardized. However, as issue #88 revealed, this may
result in a fatal build error with other environments.

So, this patch just trades that macro for the standard
'#ifdef __cplusplus' conventions (thus avoiding use of
all those '#include <features.h>' directives as well).

Reference(s):
. newlib introduced
commit a410e236ab
. procps-ng-3.3.13 issue
https://gitlab.com/procps-ng/procps/issues/88
. some additional discussion
https://www.freelists.org/post/procps/PATCH-Replace-glibcspecific-macros-in-procnumah,1
. musl wiki (see: sys/cdefs.h error messages)
https://wiki.musl-libc.org/faq.html

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-05-06 07:19:38 +10:00
Jim Warner
bae272fe22 library: eliminate inappropriate '__BEGIN_DECLS' macro
This patch simply eliminates that glibc specific macro
from all header files which contain no public callable
functions. After all, if user code can't link to them,
then protection from C++ name mangling is unnecessary.

[ we also remove any related '#include <features.h>' ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-05-06 07:19:38 +10:00
Jim Warner
c2a29d370c sysctl: relocate the procio code to a more proper home
Now that the procio logic was removed from the library
we must move the header file, lest we break make dist.

In the process, we will relocate that source file too.

[ we'll take a slightly different approach than that ]
[ used under the master branch by exploiting those 2 ]
[ non-library directories 'include' and 'lib', while ]
[ avoiding any sysctl hard coded function prototype. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-05-06 07:19:37 +10:00
Craig Small
1ddd17b17c sysctl: remove extern from non-library call
Missed removing the extern from the header file
2018-03-01 21:52:20 +11:00
Craig Small
e72f30549b sysctl: Bring procio functions out of library
The procio functions that were in the library have been
moved into sysctl. sysctl is not linked to libprocps in
newlib and none of the other procps binaries would need
to read/write large data to the procfs.

References:
 be6b048a41
2018-03-01 21:47:57 +11:00
Werner Fink
3373a58fb6 Add flexible buffered I/O based on fopencookie(3)
to be able to read and write large buffers below /proc.
The buffers and file offsets are handled dynamically
on the required buffer size at read, that is lseek(2)
is used to determine this size. Large buffers at
write are split at a delimeter into pieces and also
lseek(2) is used to write each of them.

Signed-off-by: Werner Fink <werner@suse.de>
2018-03-01 21:42:10 +11:00
Jim Warner
f341bd4632 library: expanded to provide for the UID used at login
This patch represents the newlib implementation of Jan
Rybar's merge request referenced below. It essentially
moves that code out of the ps program and into our new
library where it's available via the <pids> interface.

Reference(s):
https://gitlab.com/procps-ng/procps/merge_requests/57
https://bugzilla.redhat.com/show_bug.cgi?id=1518986

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-02-19 20:33:59 +11:00
Jim Warner
7ede9ef79f library: account for idle state ('I') threads in total
With the documentation update in the commit referenced
below, we should also account for such threads as they
will already be represented in the task/thread totals.

[ and do it in a way that might avoid future changes ]

Reference(s):
commit 91df65b9e7

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-02-12 20:58:31 +11:00
Craig Small
a935a65b77 library: Explicit about task ID string length
This removes the following error by stating the task ID can only be 10
characters wide, as it is an integer.

proc/readproc.c: In function ‘simple_nexttid’:
proc/readproc.c:1185:46: warning: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size between 41 and 51 [-Wformat-truncation=]
   snprintf(path, PROCPATHLEN, "/proc/%d/task/%s", p->tgid, ent->d_name);
                                              ^~
proc/readproc.c:1185:3: note: ‘snprintf’ output between 14 and 279 bytes into a destination of size 64
   snprintf(path, PROCPATHLEN, "/proc/%d/task/%s", p->tgid, ent->d_name);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2017-12-20 21:37:01 +11:00
Jim Warner
6634e813d4 library: correct 'use' calculations for <slabinfo> api
Awhile back, the calculation for cache utilization was
corrected to avoid a 32 bit overflow. This commit just
brings this branch into line with that earlier change.

[ references shown below represent the master branch ]

Reference(s):
commit 23ba442c88
https://gitlab.com/procps-ng/procps/merge_requests/29
http://www.freelists.org/post/procps/fix-regression-created-by-99d71ad

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-12-20 21:18:54 +11:00
Jim Warner
d53ff45b0d library: delete some obsolete parameter checking logic
This commit removes some obsolete parameter validation
code which was needed back when certain functions were
public, called directly by users (1st/2nd generation).

Now that they're static they can be safely eliminated.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-12-20 21:18:54 +11:00
Jim Warner
06be33b43e library: improve and/or standardize 'errno' management
With older library logic having been modified to avoid
using those potentially deadly alloc.h routines, while
improving 'errno' handling, we're ready to standardize
and enhance newlib's approach to any potential errors.

In so doing, we'll establish the following objectives:

. . . . . . . . . . . . . functions returning an 'int'
. an error will be indicated by a negative number that
is always the inverse of some well known errno.h value

. . . . . . . . . . . functions returning an 'address'
. any error will be indicated by a NULL return pointer
with the actual reason found in the formal errno value

And, when errno is manipulated directly we will strive
to do so whenever possible within those routines which
have been declared with PROCPS_EXPORT. In other words,
in the user callable functions defined in source last.

[ But, that won't always be possible. In particular, ]
[ all the 'read_failed' functions will sometimes set ]
[ 'errno' so that they can serve callers returning a ]
[ NULL or an int without duplicating a lot of logic. ]

[ Also, that includes one subordinate function which ]
[ was called by 'read_failed' in the <slabinfo> API. ]

------------------------------------------------------
Along the way, several additional miscellaneous issues
were addressed. They're listed here now for posterity.

. the '-1' return value passed outside the library was
eliminated since it would erroneously equate to -EPERM

. the stacks_fetch functions in <diskstats> and <stat>
weren't checked for their possible minus return values

. hash create was not checked in <meminfo> or <vmstat>

. fixed 'new' function faulty parm check in <slabinfo>

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-12-20 21:18:54 +11:00
Jim Warner
7453f8719b library: actually remove those alloc.h & alloc.c files
Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-12-20 21:18:53 +11:00
Jim Warner
18e684d65d library: eliminate all dependencies on alloc.h/alloc.c
While that old master branch library may utilize those
memory allocation functions found in the alloc module,
it was inappropriate for this newlib branch to subject
callers to a stderr message followed by an early exit.

Of course, the old libprocps offered a message handler
override provision (xalloc_err_handler) but that, too,
would seem to be inappropriate for our modern library.

[ remember the battles fought with that damn libnuma ]

So, this commit will tweak those old inherited sources
setting the stage for standardized return values/errno
settings in connection with a memory allocation error.

------------------------------------------------------
Along the way, we'll address the following miscellany:

. Completely eliminate usage of anything from alloc.h.
This, of course, entails our own error checking of the
alternative allocation calls from stdlib.h & string.h.

. Eliminate use of the strdup function where possible,
as with 'procps_uptime' and 'procps_loadavg' routines.

. Whack some obsolete code (getslabinfo) in sysinfo.c.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-12-20 21:18:53 +11:00
Jim Warner
28f405689c library: fixed miscellaneous whitespace/comment issues
. ensure whitespace exists between the code & comments
[ changing txt slightly keeps right margin alignment ]

. strive for more consistency with some comment styles
[ don't use C '/*' style where C++ '//' style exists ]

. removed the instance of double space in 1 assignment
[ still striving for consistency in whitespace usage ]

. fixed comment relating to number of 'derived fields'
[ the <meminfo> api recently added one new such enum ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-10-01 22:25:18 +11:00
Jim Warner
89775d5418 library: normalize stacks_extent struct layout, <PIDS>
This patch just rearranges 1 item in the stacks_extent
struct to make it equivalent to all the other modules.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-10-01 22:25:18 +11:00
Jim Warner
daf7c86c01 library: add delta values with swap too, <meminfo> api
As an oversight, delta values for SWAP amounts weren't
included in the <meminfo> API. Since any runtime costs
of including them only amount to slightly more storage
this commit will simply correct the earlier oversight.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-10-01 22:25:18 +11:00
Kyle Laker
3651280194 whattime: Show 0 minutes in pretty output
When supplying the -p command to uptime, it does not display any
sections where the value is less than 1; however, after a reboot, this
causes the command to just output "up". Showing 0 minutes when the
system has been up for less than a minute makes it clear a reboot just
occurred.

References:
 commit 325d68b7c3

Signed-off-by: Craig Small <csmall@enc.com.au>
2017-09-25 08:36:51 +10:00
Craig Small
d8fb86dbc5 Port of merge request 49 to newlib
Wayne Porter made !49 which added Cygwin support to the master branch
This is the port of those changes to newlib
2017-08-19 23:05:22 +10:00
Jim Warner
876aff8584 library: correct the #define FALSE_THREADS, <PIDS> api
Awhile back, that former QUICK_THREADS #define evolved
into the development (only) FALSE_THREADS which can be
used to ensure a 'duplicate ENUM' convention is output
when certain string fields can't be easily duplicated.

Unfortunately, that original implementation was marred
with zeros being displayed for /proc/$$/meminfo fields
in all the child threads for a multi-threaded process.

So this commit corrects that zero memory field buglet.

Reference(s):
. QUICK_THREADS becomes FALSE_THREADS
commit c546d9dd44

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-07-04 20:40:53 +10:00
Jim Warner
dbc880edd3 library: correct 'used' memory calculations, <meminfo>
The <meminfo> module attempted to duplicate the former
sysinfo memory calculations wherein 'SReclaimable' was
added to 'Cached' for the 'kb_main_cached' equivalent.

But, this original approach was wrong for two reasons.

1. The addition occurred too late to impact the 'USED'
calculation which could then cause an underflow in the
top memory display if 'SReclaimable' was heavily used.

2. In changing the actual /proc/meminfo 'Cached' value
it meant that users could not rely on that proc(5) man
page when interpreting the MEMINFO_MEM_CACHED results.

So this commit adds a new enumerator for the inclusive
cached amount plus repositions the calculation so that
a MEMINFO_MEM_USED result will exclude 'SReclaimable'.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-06-04 21:36:23 +10:00
Jim Warner
3d39e4fd88 library: set stage for NUMA node field display support
In response to that suggestion referenced below, these
changes allow display of task/thread level NUMA nodes.

Currently, only the 'top' program offers any NUMA type
support and it is limited to the Summary Area display.
With this commit both the 'top' and 'ps' programs will
be able to display NUMA nodes associated with threads.

Reference(s):
https://gitlab.com/procps-ng/procps/issues/58

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
618a813baa misc: eliminate all those remaining gcc -Wall warnings
Reference(s):
proc/readproc.c: In function 'statm2proc'
proc/readproc.c:600:9: warning: variable 'num' set but not used [-Wunused-but-set-variable]

proc/stat.c: In function 'stat_derive_unique':
proc/stat.c:429:1: warning: no return statement in function returning non-void [-Wreturn-type]

ps/parser.c: In function 'arg_type':
ps/parser.c:1098:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
ps/parser.c:1099:34: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'

lib/signals.c: In function 'strtosig':
lib/signals.c:243:9: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
lib/signals.c:245:13: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'

slabtop.c: In function 'print_summary':
slabtop.c:223:29: warning: unused variable 'stats' [-Wunused-variable]

watch.c: In function 'process_ansi':
watch.c:232:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
watch.c:235:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
6644b1a646 library: eliminate a redundant conditional, <PIDS> api
library: eliminate a single redundant conditional test

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
253ac7f709 library: improve <STAT> cpus offline/online management
When those standardized 'derived' TIC enumerators were
introduced, a problem with potential DELTA distortions
was also introduced when toggling cpus offline/online.

It has always been true that the 1st (summary) line in
/proc/stat will experience a decrease in total tics if
a new cpu is brought online. Such decreases are mostly
due to reductions in 'idle' and 'iowait' tics. Exactly
why such a counterintuitive phenomenon should occur is
a mystery, but this has been acknowledged in proc.txt.

A separate potential distortion arises with individual
cpus. And, here it extends to both bringing processors
online plus taking them offline too. When that happens
the order of the cpus array tracking is upset, placing
the 'new' values in some other processor's array slot.
But even if we were to occupy the same slot, the issue
regarding reductions in 'idle' & 'iowait' still apply.

In all cases, when a DELTA field was found to be minus
it was forced to zero via the 'TICsetH' macro. However
the 'derived' calculations are subject to new forms of
distortion with their own DELTA values. For example we
could find DELTA_SUM_USER + DELTA_SUM_SYSTEM exceeding
DELTA_SUM_TOTAL, an illogical/inappropriate condition.

So this commit moves former protections for individual
cpus to the stat_derive_unique() function and modifies
it to also extend protections to the 'derived' values.
In the process we now protect the cpu 'summary' counts
which were unfortunately previously overlooked (oops).

Reference(s):
. 'derived' types introduced
commit 2c86c4984a
2017-03-29 22:10:56 +11:00
Jim Warner
ea930f6f9e library <stat>: input file buffer size must be dynamic
Since its introduction, our evolved /proc/stat API has
relied on a static buffer of 8192 bytes. This approach
is probably Ok for other /proc files but it would only
accommodate around 100 processors. If such a threshold
were exceeded then this interface could never succeed.

Now days 100 processors doesn't seem at all excessive.

So this commit trades that static buffer for a dynamic
self-tuning one. And since so much former top CPU code
was already rolled into this module, we just stole the
already proven top dynamic buffer management code too.

[ this also meant switching low level unbuffered I/O ]
[ calls to standard library buffered I/O calls. that ]
[ is exactly what <slabinfo> and <diskstats> employ. ]

Reference(s):
. 1st gen readstat introduction
commit a410e236ab

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-05 06:48:38 +11:00
Jim Warner
282ee362f0 library <stat>: improve response to cpu offline/online
With the addition of those new derived SUM values, any
CPUs taken offline or brought online would distort the
historical (delta) results.  So this patch just forces
a history reset when such transitions are encountered.

Reference(s):
. derived SUM provisions introduced
commit 2c86c4984a

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-05 06:48:38 +11:00
Jim Warner
f82ac70e13 library <slabinfo>: make read function name consistent
For each of those interfaces employing a priming read,
all the other 'read' functions begin with the module's
name except this guy which began with 'read_slabinfo'.

Now, they'll all begin with their module name then end
the same with a '_read_failed' boolean hinting suffix.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-05 06:48:38 +11:00
Jim Warner
e524e48138 library: eliminate distorted history 1st time switches
Upon reflection, at the point where the 'priming read'
was introduced, any possibility of history distortions
was also eliminated.  This was true because all of the
'old' (zeroed) data will have been replaced with 'new'
data whenever a user finally calls get, select & reap.

Thus, any DELTA values will automatically reflect that
interval between 'new' and subsequent retrieval calls.

[ diskstats didn't actually employ a 1st time switch ]
[ like the others so we have changed a comment only. ]
[ but that module will retain something similar used ]
[ inside node_update whenever a new node is created. ]

Reference(s):
. priming read added to slabinfo
commit 5d5a52a380
. priming read added to diskstats
commit ecd64f4445
. priming read added to meminfo, stat, vmstat
commit 1a2b62c779

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-05 06:48:38 +11:00
Jim Warner
2c86c4984a library <stat>: standardized new category calculations
This commit arose out of the discussion (and research)
surrounding the issue cited below. It is an attempt to
consolidate and standardize the calculation of jiffies
categories (e.g. 'idle', 'busy', etc.) once & for all.

Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in
case anyone, in the future, decides to calculate usage
based upon elapsed time * Hz (like top does in process
level %CPU stats). In such an event, a total number of
CPUs or NUMA Nodes would be needed for proper scaling.

Reference(s):
https://gitlab.com/procps-ng/procps/issues/48

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-04 08:29:44 +11:00
Jim Warner
12e070dd5f library: ensure 'namespace' types treated consistently
Unlike the ps kludge under the master branch to ensure
that namespaces appear the same under both 32 & 64-bit
models, this newlib branch already used a proper type.

However source data still carried the original type as
'signed long' versus that more proper 'unsigned long'.

So, this patch makes sources & destinations identical.

Reference(s):
. master branch ps kludge
commit c41c614b0c

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-01-04 08:29:44 +11:00
Jan Rybar
5602dd04e1 library: don't strip off prefixes from the wchan names
This commit will resolve the RedHat Bugzilla #1322111.

[ import from identical commit against master branch ]
[ but without trailing whitespace, thank you so much ]

Imported by: Jim Warner <james.warner@comcast.net>
2016-12-07 22:07:00 +11:00
Jim Warner
8ba07209f0 library: accumulated miscellaneous code/comment tweaks
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-07 22:07:00 +11:00
Jim Warner
e70531a945 library: protect against possible 'refcount' underflow
In each module employing a priming read at 'new' time,
should that read fail, a call to 'unref' will be made.

However, there is a hidden dependency that these calls
must never occur before the context 'refcount' was set
due to the way an 'unref' conditional was constructed.

So this commit just ensures that 'unref' will function
as expected, even if called with a 'refcount' of zero.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-07 22:06:59 +11:00
Jim Warner
912075605b library <stat>: remove that PIDS_WCHAN_ADDR enumerator
Removing the Item_table 'stat' oldflags for WCHAN_ADDR
was wrong since that 'stat' field is not a constant 0.
Rather, it could assume these 3 values: -1, 0, and +1.

I have not been able to pin down a '-1' result, but it
probably means some sort of permission error (-EPERM).

The '1' or '0' values were supposed to distinguish the
tasks that were or were not blocked (whether there was
a wchan address). However, in practice there is little
correlation between those values and availability of a
kernel symbol in /proc/$$/wchan (perhaps due to race).

Anyway, the real point is that a 'stat' wchan does not
now intentionally contain an address. Thus, outputting
'ffffff', '-' or '1' in programs like ps is senseless.

So this patch just eliminates PIDS_WCHAN_ADDR from our
item enumerators leaving only the PIDS_WCHAN_NAME guy.
Now the new library can't be blamed for bad addresses!

Reference(s):
. removed Item_table 'oldflags'
commit c4aa6c0ab4
. linux removal of wchan addresses
commit b2f73922d119686323f14fbbe46587f863852328

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-10-16 08:23:38 +11:00
Jim Warner
71bd5b6485 library <pids>: remove fields obsoleted with linux 2.6
It seems inappropriate to blindly include fields known
to always be zero in our brand new library. Therefore,
this patch removes support for three such enumerators.

[ that stat 'it_real_value' (PIDS_ALARM) field could ]
[ have been made obsolete before a linux 2.6 release ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-10-09 21:31:29 +11:00
Jim Warner
82a0dcda0f library: strictly cosmetic, absolutely no code changes
This commit just contains some tweaks to comments plus
a few adjustments to whitespace for alignment purposes
and a normalization of the header inclusion #define's.

[ plus a spelling error in one header file was fixed ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-10-09 21:31:29 +11:00
Jim Warner
9d1f6cb4ea library <stat>: added overlooked numa guest tic counts
When this module was upgraded to 3rd generation in the
patch referenced below, numa node support was migrated
from the top program into newlib. The 'guest_nice' and
'guest' tics were overlooked as top did not need them.

So, this commit corrects that oversight and achieves a
proper symmetry between the cpu & numa jiffies counts.

Reference(s):
. 3rd gen redesign, numa support imported
commit abc71a46ad

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-26 07:40:45 +10:00
Jim Warner
1a2b62c779 library: add priming read at 'new' time <most modules>
A priming read at 'new' time in that <slabinfo> module
was important so that permission problems are detected
early. Plus, it also had the potential of making delta
values valid when 'get' or 'select' were first called.

It is for that latter reason that such a read was also
incorporated in the <diskstats> module 'new' function.
No other module, however, employed such priming reads.

This patch just brings those potential benefits to all
of our other newlib modules with the exception of that
<pids> guy. That module is, of necessity, sufficiently
different from those others to justify such exclusion.

Not only are there precious few DELTA enums in <pids>,
but the costs of a priming read would be much greater.

[ otherwise, these newly added priming reads have no ]
[ measurable negative impact on performance/timings. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-21 21:06:12 +10:00
Jim Warner
5197fa0a71 library: summary name now more descriptive, <slabinfo>
The <slabinfo> header provides 3 groups of enumerators
with prefixes of SLABINFO, SLABS & SLABNODE. The first
is strictly user oriented & isn't supported internally
by any structure. The other two, however, have structs
associated with 'em but, unfortunately, 1 is misnamed.

The 'struct slabs_node' is associated with 'nodes' and
supports the enumerators with the SLABNODE prefix. But
the 'struct slabs_hist' was associated with 'hist' yet
supports those enumerators with just the SLABS prefix.

We do not care very much what some structure is called
but we do care about an identifier used manipulate it.

This patch will trade the 'hist' identifier associated
with 'struct slabs_hist' for a more congruous 'slabs'.

[ it's awful when the author can't remember what the ]
[ true meaning of an identifier is after creating it ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-21 21:06:12 +10:00
Jim Warner
eeeba3e66c library: improve support of dynamic numa nodes, <stat>
If, in fact, numa nodes are dynamic (like that current
total of on-line cpus) the existing logic was lacking.
It included an early return before checking the total.

So, this commit ensures that the nodes total is always
set or updated consistently in only a single function.
There's no need to set it at the time 'new' is called.

[ and since under our existing code this nodes total ]
[ could never possibly have been zero, the erroneous ]
[ test (with the early return) has now been whacked! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-21 21:06:12 +10:00
Jim Warner
91d47123f2 library: finally circumvent libnuma memory leak <stat>
Still unhappy with a minor memory leak associated with
libnuma, I experimented with omitting the dlclose that
was issued at module's end. For some reason which will
remain a mystery, the valgrind leak then went bye-bye.

So this patch just omits one use of dlclose and relies
on whatever kernel magic is at work to free the memory
when each process ends. We kept, however, the original
code (now commented-out) to serve as a future caution.

There remains one potential (but unlikely) dlclose use
near the original dlopen. But there will be no leak as
that 'numa_node_of_cpu' will not yet have been called.
This seems to be the culprit that triggers such leaks.

None of this libnuma shit would likely have come close
to hitting our fan had the numa developers provided us
with 'new' and 'unref' functions like our newlib does.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-18 20:37:24 +10:00
Craig Small
a8f7e44233 docs: Remove old library man pages 2016-09-11 11:20:03 +10:00
Jim Warner
834ed434c9 library: normalize stack and history allocation naming
Recent profiling and timings have resulted in improved
newlib performance. This patch completes that process.

It just normalizes naming conventions employed for all
allocations involving reaped stacks & history support.

The modules offering a 'reap' function will also offer
the now standardized corresponding STACKS_INCR define.

The modules which provide dynamic history support will
now have a separate #define called NEWOLD_INCR used in
allocations/reallocations. And, while values currently
are set equal to that STACKS_INCR value, in the future
some reason for divorcing those two may be discovered.

----------------------------- for future reference ---

In those modules which contain the STACKS_INCR #define
it is tempting to specify a large value so as to avoid
repeated calls to malloc/realloc. However, in doing so
an extra runtime price will be paid in 'cleanup_stack'
calls with any iterative programs like top or slabtop.

So, with the current values a balance has been sought.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-11 09:31:05 +10:00
Jim Warner
3ac040d047 library: revert one ancient 'escape_str_utf8' deletion
Profiling revealed a large amount of time spent in the
'escape_str_utf8' function (escape.c) with both of our
NLS branches (newlib and master). That same result was
not seen under an ancient top-3.2.8 program & library.

Well, the 3.2.8 result was ultimately explained by the
absence of a 'setlocale', necessary under NLS support.
Thus, when that ancient library tested for locale, all
it got was 'ANSI_...' & assumed 'UTF-8' wasn't active.

But after a hack to that ancient code to place it on a
par with newlib/master, I still found cost differences
that led me to revisit an old change referenced below.

It turns out that 'iswprint' costs far more than would
a call of 'isprint', even with the extra support code.
So this commit just reverts that five year old change.

Reference(s):
commit 7b0fc19e9d

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-23 21:11:09 +10:00
Jim Warner
acda6f40d1 library: miscellaneous additional efficiencies, <pids>
This patch contains the following miscellaneous stuff:

. The pids_stacks_fetch() routine might call for newly
allocated stacks to be itemized. However, that job was
already tended to by the pids_stacks_alloc() function.

So, this patch just eliminates a redundant invocation.
------------------------------------------------------

. The concept of 'dirty_stacks' has not kept pace with
the evolving stacks implementation. Originally, stacks
were considered dirty only if free() of dynamic memory
was needed before refreshing any single result struct.

Later, with the introduction of the 'extra' item and a
promise to reset it to zero, 'dirty' was much broader.

So, this patch just treats the dirty flg as others do.
------------------------------------------------------

. Lastly, a word or three about performance & timings.

Tuning efforts concentrated on the <pids> API and top.
And unless an oldlib equivalent to the preceding patch
is applied (favoring stat vs. status), newlib top will
often outperform the oldlib version (obviously wrong).

So assuming /proc/stat is preferred in both libraries,
generally speaking, a cpu and elapsed time increase of
1-5% was found for this new stacks oriented interface.
Of course, there's also an increased memory footprint.

There are some occasions, however, when the newlib top
is at a substantial disadvantage. For example if WCHAN
or TTY is displayed, such items will be present in all
newlib reaped stacks (i.e. every process). But old top
would only incur such overhead with displayable tasks.

Thus, oldlib top could outperform newlib by up to 25%,
for example, if only fields requiring NO library flags
were displayed. However, such a scenario is not likely
since only GID, UID, PID, TGID & WCHAN would be shown.
In the usual case, that overhead associated with WCHAN
and/or TTY is overshadowed by other top runtime costs.

All in all a pleasing outcome I deem quite acceptable.
------------------------------------------------------

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-23 21:11:09 +10:00
Jim Warner
e9c101edcb library: prefer /proc/stat before /proc/status, <pids>
Long ago, in a galaxy far away (when top was in charge
of library FILL flgs) /proc/status was to be preferred
over /proc/stat if a field could be satisfied by both.

This was done to avoid costly 64-bit math emulation in
a 32-bit application due to 'unsigned long long' data.

Well it's time to acknowledge the prevalence of 64-bit
platforms. And in such an environment the cost picture
has shifted significantly. It now costs 14 times (wow)
as much to access /proc/status compared to /proc/stat.

In other words, even with '%llu' variables, a sscanf()
call in stat2proc() beats the pants off that home brew
gperf based hashing employed by the status2proc() guy.
In fact, status2proc incurs higher costs than found in
the most expensive aspect of top's forest view option.

Here's a gprof extract to illustrate the costs. It was
produced with an rcfile requiring fields from both the
/proc/stat & /proc/status pseudo files (among others).
There were 5000 iterations in each of 4 separate gprof
runs subsequently merged into 1 gmon.sum for analysis.

  %      self              self
 time   seconds    calls  us/call  name
 -----  -------  -------  -------  -----------
 28.65     4.10  4689423     0.87  status2proc
 26.14     3.74    40000    93.50  forest_adds
 ...
 01.96     0.28  4689427     0.06  stat2proc

[ since forest_adds is recursive, the calls value is ]
[ the non-recursive #, its 'call graph' shows totals ]

Anyway, now that such cost is known this patch becomes
what is euphemistically known as the usual no-brainer.

[ jeeze, was it really this long between profilings? ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-23 21:11:09 +10:00
Jim Warner
4fe42d0be9 library: most function names now more profile friendly
This patch will begin some refinements associated with
gprof. Initially, functions names have been changed to
help in identifying potential bottlenecks. This effort
also included the obscure set, free and sort routines.

Plus the following additional modifications were made:

. the stacks_alloc prologue was generalized plus added
to a couple of modules where it had not yet propagated

. a couple of the '// end ...' comments were corrected

. some functions have been formally tagged as 'inline'

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-23 21:11:09 +10:00
Jim Warner
4f2fe6411e library: expand fields and break an ABI, <MEMINFO> api
The immediately prior commit demonstrated how our APIs
might be expanded in at some point in the future while
maintaining binary compatibility in previous programs.

However, since we've yet to release the 1st version of
our new library, there's no need to violate alphabetic
ordering just yet. So, this patch restores that order.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-16 21:08:27 +10:00
Jim Warner
09e1886c9e library: expand fields yet maintain ABI, <MEMINFO> api
With the 4.8 kernel, 2 new fields will be added to the
meminfo pseudo file. This commit, soon to be replaced,
is intended as an example of how such changes might be
incorporated plus still maintain binary compatibility.

This actually goes further than is strictly necessary,
by retaining meminfo_item ordering for 'set' functions
and the creation of hash table entries. However, there
is only 1 true requirement, that of Item_table entries
which must always agree exactly with item enumerators.
All of the other changes could be done alphabetically.

Ok, so what happens when an old program encounters the
new expanded meminfo items? Well, if it was thoroughly
tested against an old library, it won't even see those
new fields. On the other hand, if it somehow exceeds a
previous MEMINFO_logical_end, then it will just get an
extra result structure or two, with no real harm done.

[ this patch is being replace by the very next patch ]
[ so that our iniitial newlib release can maintain a ]
[ strict alphabetic ordering in all areas initially! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-16 21:08:27 +10:00
Jim Warner
530d19f90f library <STAT>: exclude an #include for --disable-numa
When the numa stuff was imported from the top program,
that #include for dlopen() was not made conditional as
it should have been. Well, here it is being corrected.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 07:57:55 +10:00
Jim Warner
7d20df9ef0 library: if the VAL type is wrong still return a value
Rather than return a 0 result for all VAL type errors,
return what would have been without validation active.

This will enable a program like pgrep to still print a
result even though it used some incorrect type member.

With this commit, our VAL macro validations logic will
behave in exactly the same way as the GET validations.
While warning messages may be issued, except for a bad
enumerator, values will always be returned to callers.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 07:56:00 +10:00
Jim Warner
9f27e9d8d9 library: strengthen the VAL macro validation functions
One ought not to assume that random memory access will
always succeed or, when it does, that an obviously bad
item enumerator will always be found at that location.

Thus, this patch corrects some really poor assumptions
associated with the 'xtra_procps_debug.h' header file.

[ and it does so in somewhat contorted ways so as to ]
[ avoid several darn gcc -Wnonnull warning messages! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 22:01:37 +10:00
Jim Warner
bef8c7fb70 library: ensure that all those 'GET' macros are robust
When users call the native 'get' functions they have a
responsibility to check that the result struct address
was indeed returned. But when using those 'GET' macros
there was no protection for possible NULL dereference.

So this patch will add some protection for a potential
failure of an underlying 'get' function. And should it
occur then those 'GET' macros will just return a zero.

Plus, we'll also mirror that behavior in the debugging
header should the XTRA_PROCPS_DEBUG #define be active.
And, we might as well add a warning when invalid items
are passed to 'GET' macros, just like we do for 'VAL'.

[ lastly, we added the missing opening parens/braces ]
[ to 2 'GET' macros in that xtra-procps-debug.h file ]
[ which went unnoticed until the qa folks caught up. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-07 21:43:38 +10:00
Jim Warner
e3270d463d library: provide for validating result type references
During development, we now have a means for validating
that a type referenced in application code matches the
actual type set by the library. The new feature can be
activated through either of the following two methods:

1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms)

2) an #include <proc/xtra-procps-debug.h> (single pgm)

[ in the future, one could add a formal configure.ac ]
[ provision. but for now a manual approach is safer. ]

Lastly, for any module which provides a sort function,
the handling for both 'noop' & 'extra' enumerators was
made consistent. Now, 'noop' is not sorted and 'extra'
will be sorted as that module's widest supported type.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-07 21:40:48 +10:00
Jim Warner
6cafe3abec library: expand VAL macros to include the context parm
This patch will set the stage for validating the types
referenced in the result union. For now, the parameter
representing that 'info' structure will remain unused.

[ and while we're at it, let us correct a faulty GET ]
[ macro in the diskstats header. that puppy missed a ]
[ parm which ain't so good if that guy is ever used! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-07 21:40:48 +10:00
Jim Warner
c4aa6c0ab4 library: normalize & minimize result types, <PIDS> api
This commit attempts to minimize the variety of types
currently used. Plus, the following were also changed:

. the MEM fields were switched to parallel the VM guys
. PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS
. PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT

. made NICE 's_int' so that it then parallels PRIORITY

. change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int'

. removed Item_table 'oldflags' for an obsoleted field
. PIDS_WCHAN_ADDR

. added calculations like TICS_ALL_C for the following
. PIDS_TICS_USER_C
. PIDS_TICS_SYSTEM_C

. these three new 'TICS' fields have been incorporated
. PIDS_TICS_BLKIO - jiffies spent in block i/o
. PIDS_TICS_GUEST - jiffies spent as a guest
. PIDS_TICS_GUEST_C - as above, includes dead children

. that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA
( so it did not hide between TICS_BLKIO & TICS_GUEST )
( and to make clearer what's included: utime + stime )

. eliminated 'sl_int' entirely from that result struct

[ often, the <pids> module changes necessitated that ]
[ readproc header and source files had to change too ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-01 20:09:18 +10:00
Jim Warner
01beb85f7d misc: replace any remaining tab characters in readproc 2016-08-01 20:09:18 +10:00
Jim Warner
6f71a33c1d library: add final remaining sort function, <STAT> api
With this patch, all of the modules which offer a reap
function (pids, diskstats, slabinfo and stat too) will
now also provide for sorting whatever had been reaped.

It was easy to overlook a sort function for our <STAT>
guy given the paucity of CPUs on your typical personal
desktop or laptop. However, out in the world one might
find boxes with hundreds of CPUs plus many NUMA nodes.

Hey, who are we to disallow sorts on something another
person might see as useful under the above conditions?
And, there's always something to be said for symmetry.

[ of course, several minor tweaks were also included ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-28 20:46:18 +10:00
Jim Warner
5c857b865e misc: tweaks (mostly cosmetic) to several source files
. a more appropriate error return code was substituted
. a safer form of comparison is utilized in two places
. a STAT_VAL macro replaced by more proper MEMINFO_VAL
. several of the silly 'xerrx' formats had been missed
. a few whitespace changes have also been incorporated

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-28 20:46:18 +10:00
Jim Warner
612f36189e related: change for lost 'PROCPS_' enumerator prefixes
With this patch we've completed a progression toward a
standard approach to naming conventions which follows:

* Only functions will begin with that 'procps_' prefix
. ........................................... examples
. procps_vmstat_get ()
. procps_diskstats_select ()
- ----------------------------------------------------

* Exposed structures begin with the module/header name
. ........................................... examples
. struct pids_info
. struct stat_reaped
- ----------------------------------------------------

* Item enumerators begin like structs, but capitalized
. ........................................... examples
. VMSTAT_COMPACT_FAIL
. MEMINFO_DELTA_ACTIVE

[ slabinfo varies slightly due to some item variants ]
. SLABINFO_extra
. SLABS_SIZE_ACTIVE
. SLABNODE_OBJS_PER_SLAB
[ could cure with a prefix of SLABINFO, but too long ]
- ----------------------------------------------------

* Other enumerators work exactly like item enumerators
. ........................................... examples
. PIDS_SORT_ASCEND
. STAT_REAP_CPUS_AND_NODES
- ----------------------------------------------------

* Macros and constants begin just like the enumerators
. ........................................... examples
. #define SLABINFO_GET
. #define DISKSTATS_TYPE_DISK
- ----------------------------------------------------

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-26 20:49:44 +10:00
Jim Warner
c4d097c709 library: removed all the 'PROCPS_' enumerator prefixes
Many of our item enumerator identifiers are very long,
especially in that <VMSTAT> module. Additionally, they
all contain the exact same universal 'PROCPS_' prefix.

The origins for this are likely found in the desire to
avoid name clashes with other potential include files.
But with procps-ng newlib, we've probably gone way too
far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more
protection against clash than 'PIDS_TICS_SYSTEM' does?

I don't think so. Besides, no matter how big that name
becomes, one can never guarantee they'll never be some
clash. And, conversely, extremely short names will not
always create conflict. Of course, in either case when
some clash occurs, one can always #undef that problem.

Thus, this commit will eliminate that 'PROCPS_' prefix
making all of those enum identifiers a little shorter.
And, we'll still be well above some ridiculously short
(criminally short) names found in some common headers:

- - - - - - - - - - <term.h>
- 'tab', 'TTY', etc
- - - - - - - - - - - - - - - - <search.h>
- 'ENTER', ENTRY', 'FIND', etc

------------------------------------------------------
Finally, with this as a last of the wholesale changes,
we will have established the naming conventions below:

. only functions will begin with that 'procps_' prefix
. exposed structures begin with the module/header name
. item enumerators begin like structs, but capitalized
. other enumerators work exactly like item enumerators
. macros and constants begin just like the enumerators
------------------------------------------------------

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-26 20:49:00 +10:00
Jim Warner
d7cbf3448f related: adapt to changes in 'context' structure names
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-26 20:47:50 +10:00
Jim Warner
82d5661603 library: standardize all the 'context' structure names
This patch attempts to standardize the naming of those
most important (declared not defined) context structs.

The present practice represents a hodge podge of names
only some of which reflect the source /proc file name.
And 2 of those file names embed a literal 'info' which
is likely the origin of that required parm identifier.

Now we'll append a universal '_info' to such structure
names, while including the names of those /proc pseudo
files where possible. In any case, that context struct
will *always* begin with the actual module/header file
name. And only the following two sound a little weird!

---------> 'meminfo_info' + 'slabinfo_info' <---------

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-26 20:47:34 +10:00
Jim Warner
ecd64f4445 library: normalize/standardize an i/f, <DISKSTATS> api
This patch will bring this interface up to our 3rd gen
standards. The following summarizes the major changes.

* New delta provisions have been added to most fields.

There are, of course, some fields for which a delta is
inappropriate. They include the identifying items such
as name, type, major and minor. Plus the io_inprogress
field which already acts, in effect, as a delta value.

* To provide delta support, dev_node historical values
have become persistent. By the same token, the library
must provide for future removal of disks/partitions. A
timestamp is used to detect 'stale' data which will be
deleted so as not to satisfy some get, select or reap.

* Such persistent support is provided by a linked list
which, by default, grows from the bottom down so as to
maintain compatibility with the /proc/diskstats order.

Initially, I was tempted to use the GNU tsearch (tree)
provisions until I discovered the overhead of building
that tree plus costs of a subsequent 'twalk'. Besides,
walking such a tree means retrieval order would differ
from an order required/expected by the vmstat program.

* The '/sys/block' directory is no longer scanned with
every refresh cycle. Rather, it's only accessed when a
node is first encountered. Then, that node's 'type' is
persistent for its lifetime like several other fields.

* A sort provision was included, at virtually no cost,
even though such a provision was not currently needed.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-26 20:46:08 +10:00
Jim Warner
8e5d5e44e9 library: rename 'diskstat' source as 'diskstats' files
Where possible, libprocps files convey the name of the
actual source pseudo file under the '/proc' directory.

This brings diskstats into line with such an approach.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-26 07:59:52 +10:00
Jim Warner
338166df57 misc: just eliminate several 'unused' warning messages
[ plus we also play catch up on some earlier changes ]
[ that impacted skill.c, after using --enable-skill! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-26 07:59:48 +10:00
Jim Warner
220236a9af library: some minor miscellaeous improvements, 3rd gen
A collection of miscellaneous code and comment tweaks.

[ such changes will stop when desk checking ends too ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-17 08:49:48 +10:00
Jim Warner
c546d9dd44 library: recycle the QUICK_THREADS #define, <PIDS> api
That #define QUICK_THREADS was impossible to implement
under the new <pids> interface. Plus it was also found
to distort some thread information (referenced below).

So, it's always been inactive under the newlib branch.

However, it will (with small changes) still serve some
useful purpose in our library. Now, when the redefined
FALSE_THREADS is active, those special strings showing
"[ duplicate ENUM ]" will appear for any child thread.

Note: the real reason for such strings appearing isn't
being exercised, only their mechanics. In actual usage
they are substituted when a user duplicates such items
in a results stack & only the 1st instance can own it.

With this patch, we are simply fooling the <pids> code
into thinking an item was duplicated via a NULL value.

Reference(s):
. from master branch
commit 25a6ecdbfb

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-17 08:49:48 +10:00
Jim Warner
9bea1b2def library: the overlooked twerks (oops, tweaks), 3rd gen
Yes, all of these changes are strictly cosmetic. It is
likely symptomatic of some deep-seated character flaw.

[ or, it might be because of a certain pride in this ]
[ new library and the desire to make it even better! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-09 12:48:28 +10:00
Jim Warner
a6115bfff4 library: some tweaks to 2 file read functions, 3rd gen
Ever since their introduction, plus continuing through
several evolutions, both the meminfo and vmstat 'read'
functions employed a 'do while' loop for /proc access.

However, that loop construct was wrong since identical
tests were already done (twice!) within each loop body
itself, then accompanied by its own 'break' statement.

So, we will now transform them both into forever loops
which will help us to emphasize such break statements.

[ plus, let's return an error should nothing be read ]

[ lastly, eliminate 1 erroneous PROCPS_EXPORT prefix ]

Reference(s):
. original meminfo introduction
commit a20e88e4e7
. original vmstat introduction
commit a410e236ab

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-06 21:36:37 +10:00
Simon Tatham
f888a30d23 library: find tty device name of process quicker
The procps library attempts to work out the tty of a process
through several methods. For things like /dev/tty123 or
/dev/foo it works fine.

For tty devices that put the minor number in a directory
of the major name this fails. So then we have to fallback
to stating things like the processes STDERR and try again.

Considering a lot of processes sit on ttys such as
/dev/pts/3 this is a lot of wasted time. At the point of
entering driver_name we know "/dev/pts" and we know "3"
we just didn't join them up the right way as this is old
code.

This change now looks for /dev/pts/3 as well. It does it
after looking for /dev/pts3 so the behaviour is the same.

References:
 https://bugs.debian.org/770215

Signed-off-by: Craig Small <csmall@enc.com.au>
2016-07-03 10:47:25 +10:00
Jim Warner
80ad63dc31 library: refactor exposed pointers management, 3rd gen
This commit brings all of those 'fetch' type functions
(supporting some form of 'reap') into closer alignment
with one another. The biggest impact is to be found in
the <stat> module, which now provides for the separate
copy of stack pointers which will be exposed to users.

The reason such a copy was not employed initially with
<stat>, unlike those for <pids> and <slabinfo>, is due
to the fact that such stacks were never sortable. Thus
the original raw consolidated extent pointers wouldn't
have been disturbed. But that meant no NULL delimiter.

So with this commit, all reap/fetch operations now use
pointer copies when returning results to callers. And,
all such arrays are now NULL delimited meaning callers
can choose their own access fencepost: totals or NULL.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-02 16:33:01 +10:00
Jim Warner
4fe52ccd44 library: reduce copies of items to minimum, <STAT> api
This commit will consolidate the three separate copies
of the item enumerators currently supporting that reap
function (summary, cpus & nodes) into one shared copy.

That select function will continue to maintain its own
dedicated items copy, albeit via a new item structure.

[ and while we're at it, we'll move the 'select' guy ]
[ to its proper alphabetical place, after our 'reap' ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-02 16:33:01 +10:00
Jim Warner
8cd1214aac library: stop treating lxcname differently, <PIDS> api
Unlike other cached string fields (such as USER name),
that lxcname field was defined as 'const char *'. This
required a custom 'set' function using a cast in order
to avoid a compiler warning regarding that assignment.

So this commit brings lxcname into line with all those
other cached string fields. And while we're at it, the
reason some string fields have no 'freefunc' will also
be explained with some new comments in the Item_table.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-02 16:33:01 +10:00
Jim Warner
eff9fbc06e library: standardize extents_free_all() logic, 3rd gen
As those 3rd generation newlib APIs evolved so too did
the extents_free_all() function. Most versions of this
function required the callers to first verify that the
extents anchor wasn't empty, which was poor etiquette.

This simple function should have been much more robust
and forgiving. With this commit, it fnally becomes so.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-02 16:33:01 +10:00
Craig Small
96e6600c84 library: Cater for 32 char device names
The new library has this boundary set in a define.
Also fixed the off-by-one problem with the buffer and scanf

References:
 commit 1794875ab6
2016-07-02 15:01:11 +10:00
Jim Warner
380253ff7f library: more pids_fetch struct opaqueness, <PIDS> api
With all our 3rd generation interfaces, we're now well
positioned to preserve binary compatibility should new
fields be added to any public structure (assuming that
the 'result' union already contains its largest type).

This remains true even for the <pids> interface, which
unlike the others, has one structure embedded within a
separate struct rather than declaring a pointer to it.

The counts struct was positioned after the stacks ptrs
array so as to preserve that ABI if ever new ints were
added. Logically, however, the counts (especially that
total) should precede the stacks array if we wished to
properly place a horse (total) before a cart (stacks).

So to enable relocating those counts we will no longer
embed that structure, but provide a pointer to it. And
this will make accessing syntax feel more natural too.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-28 21:11:25 +10:00
Jim Warner
ddb4754b33 library: partial revert of that numa 'fix', <STAT> api
This patch represents the partial revert of the commit
referenced below. And, so that yours truly (the author
for goodness sake) doesn't shoot his tootsies again in
the future, a cautionary programmer comment was added.

Reference(s):
commit dea4033418

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-28 21:11:25 +10:00
Jim Warner
8444a6fe0b library: a couple of miscellaneous changes, <PIDS> api
This patch represents the following minor adjustments:

. old PROCTAB used with select & reap more descriptive

. reformatted PROCPS_PIDS_VAL macro like other 3rd gen

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Jim Warner
e41b40e6b0 library: <SLABINFO> api, change that 'get' return type
The following commit message is shared with 4 patches.
------------------------------------------------------

Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.

That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.

This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.

The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.

[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Jim Warner
8f1fb67a78 library: <MEMINFO> api, changed that 'get' return type
The following commit message is shared with 4 patches.
------------------------------------------------------

Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.

That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.

This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.

The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.

[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Jim Warner
e8d7f869b5 library: <VMSTAT> api, change in the 'get' return type
The following commit message is shared with 4 patches.
------------------------------------------------------

Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.

That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.

This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.

The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.

[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Jim Warner
8c7f89ad8d library: <STAT> api, change for that 'get' return type
The following commit message is shared with 4 patches.
------------------------------------------------------

Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.

That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.

This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.

The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.

[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Jim Warner
dea4033418 library: bug fix if libnuma.so unavailable, <STAT> api
All our numa logic was well encapsulated under #ifndef
NUMA_DISABLE (as ./configure --disable-numa), with the
exception of 1 case label. The reason it didn't create
any problems is because the sole consumer (top) itself
responded to the presence of #define NUMA_DISABLE too.

But if that option wasn't used, an oops still awaited.

When experimenting with a 32-bit library plus a 64-bit
kernel, a bug was revealed should the numa library not
have been found. Our 'reap' function must tolerate the
potential of a 0 return from that stacks_fetch_tics().

Now, if numa is desired but not possible, we'll be ok.

[ and, we'll build numa history from fresher sources ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Craig Small
5a244c1095 library: rename clashing pwcache functions
On MacOS the system already has user_from_uid and group_from_gid.
These are renamed pwcache_get_user and pwcache_get_group.

They were also exported but did not appear in the symbol file
or used by any of the procps binaries. They are no longer exported.

References:
 https://gitlab.com/procps-ng/procps/issues/34

Signed-off-by: Craig Small <csmall@enc.com.au>
2016-06-18 08:17:45 +10:00
Jim Warner
d7100d071d library: optional parms protection missing, <PIDS> api
When those items were made dynamic at 'new' time, some
other functions, previously assured of their presence,
failed to verify a 'reset' had acually been requested.

This commit just corrects that oversight and avoids an
attempt to 'assign_results' when no items are present.

Reference(s):
. when items/numitems became optional
commit 9ebadc1438

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-17 21:44:29 +10:00
Jim Warner
4a0e974b7f library: more tweaks for code and/or comments, 3rd gen
Following is a summary of significant changes (if any)
to each of these now upgraded 3rd gen library modules.

<meminfo> ............................................
. eliminated duplicate decl of 'struct procps_meminfo'
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. how did i miss relocating all these friggin' #undefs
. cleanup 'get' return logic (remove a redundant 'if')

<pids> ...............................................
. repositioned the procps_pidsinfo structure in header
. removed the extra trailing comma from enum pids_item
. standardized/normalized results struct union members

<slabinfo> ...........................................
. corrected comment typo (jeeze, in an 'aligned' para)
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. removed an obsolete #undef from procps_slabinfo_sort
. cleanup 'get' return logic (remove a redundant 'if')

<stat> ...............................................
. how did i miss relocating all these friggin' #undefs
. corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix
. removed the extra trailing comma from enum stat_item
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. strengthen those parm checks in procps_stat_get func
. cleanup 'get' return logic (remove a redundant 'if')

<vmstat> .............................................
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. cleanup 'get' return logic (remove a redundant 'if')

[ virtually all of these tweaks reflect the author's ]
[ continuing pursuit of an unreasonable goal -- that ]
[ of a 'perfect' (plus 'pretty') C language program! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-17 21:44:29 +10:00
Jim Warner
92c72166db library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.

[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]

[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-13 10:33:37 +10:00