stress-ng adds more features

Since I last wrote about perf being added to stress-ng back in the end of May I have been busy in my spare time adding more features to stress-ng.

New stressors include:

• ptrace - traces a child process performing many simple system calls
• sigsuspend - sends SIGUSR1 signals to multiple children waiting on sigsuspend(2)
• sigpending - checks if SIGUSR1 signals are pending on a process that alternatively masks and umasks this signal
• mmapfork - rapidly spawn multiple child processes that try to allocate a chunk of free memory (and try to avoid swapping). Each process then uses  madvise(2) to hints before and after the memory is memset and then the child dies.
• quota - exercise various quotactl(2) Q_GET* commands
• sockpair - client/server socket I/O using socket pair and random sized I/O
• getrandom - exercise the new getrandom(2) system call
• numa -  migrates a memory mapped buffer and processes around NUMA modes, exercising migrate_pages(2), mbind(2) and move_pages(2).
• fcntl - exercises the fcntl(2) commands F_DUP, FDF_DUP, FD_CLOEXEC,  F_GETFD,  F_SETFD, F_GETFL, F_SETFL, F_GETOWN, F_SETOWN, F_GETOWN_EX, F_SETOWN_EX, F_GETSIG and F_SETSIG
• wcs - exercises libc wide character string functions (thanks to Christian Ehrhardt for this contribution).

 ..and I have added some improvements too:

• --yaml option to dump stats from --metrics, --perf, -tz into a YAML structured log.
• made the --aggressive option more aggressive by forcing more CPU migrations and context switches.

I have also added a thermal zone stats gathering option --tz to see how warm the machine is getting when running a test.  For example:

... where x86_pkg_temp is the CPU package temperature and acpitz are the two ACPI thermal zones on my desktop.

Stress-ng is being used to run stress test various kernels across a range of Ubuntu devices, such as phone, desktop and server.   Thrashing a system with hundreds of processes and a lot of low memory pressure is just one method of checking that kernel and daemons can handle a mix of demanding work loads.

stress-ng 0.04.12 is now available in Ubuntu Wily.   See the stress-ng project page for more details.

New ACPI table tests in fwts 15.07.00

The Canonical Hardware Enablement Team and myself have been working on some significant improvements and changes to the Firmware Test Suite 15.07.00 over the past several weeks.  This cycle has been focused on adding more ACPI table testing support:

1. Added ACPI table tests:

• BERT (Boot Error Record Table)
• BGRT (Boot Graphics Resource Table)
• BOOT (Boot Table)
• CPEP (Corrected Platform Error Polling Table)
• CSRT (Core System Resource Table)
• DBG2 (Debug Port Table 2)
• DBGP (Debug Port Table)
• ECDT (Embedded Controller Boot Resources Table)
• ERST (Error Record Serialization Table)
• FACS (Firmware ACPI Control Structure)
• HEST (Hardware Error Source Table)
• LPIT (Low Power Idle Table test)
• MSDM (Microsoft Data Management Table)
• SLIC (Software Licensing Description Table)
• SLIT (System Locality Distance Information)
• SPCR (Serial Port Console Redirection Table)
• SPMI (Service Processor Management Interface Description Table)
• SRAT (System Resource Affinity Table)
• TCPA (Trusted Computing Platform Alliance Capabilities Table)
• UEFI (UEFI Data Table)
• WAET (Windows ACPI Emulated Devices Table)
• XENV (Xen Environment Table)

2. Moved the following tests out of the generic "acpitables" test into their own ACPI table tests:

• FADT (Fixed ACPI Description Table)
• HPET (HPET IA-PC High Precision Event Timer Table)
• GTDT (GTDT Generic Timer Description Table)
• MADT (Multiple APIC Description Table)
• RSDP (Root System Description Pointer)
• RSDT (Root System Description Table)
• SBST (Smart Battery Specification Table)
• XSDT (Extended System Description Table)

3. Updated ACPICA to version 20150616 and also 20150619 (ACPICA is used for the assembler/dissassembler and execution engine).

4. Renamed the --uefi and --acpi options to --uefitests and --acpitests respectively.

5. Improved fwts built-time regression tests.  To ensure future changes don't break fwts, we have added more regression tests to sanity check fwts ACPI table tests. Quality matters to us.

This release also incorporates some important bug fixes too, such making the acpidump dump file loading parser more robust, updating the SMM Communication fields on the UEFI table and fixing a segfault in the regular expression kernel log scanner on 32 bit systems.

For the next release of fwts, we are planning to continue to add table more tests from ACPI 5.x and ACPI 6.0 to get full coverage.

As ever, like all releases, for more details please consult the change log and the release notes.

Firmware Related Blogs

More often than not, I'm looking at ACPI and UEFI related issues, so I was glad to see that  Vincent Zimmer has collected up various useful links to blogs that are Firmware Related.   Very useful, thanks Vincent!

Static code analysis on kernel source

Since 2014 I have been running static code analysis using tools such as cppcheck and smatch against the Linux kernel source on a regular basis to catch bugs that creep into the kernel.   After each cppcheck run I then diff the logs and get a list of deltas on the error and warning messages, and I periodically review these to filter out false positives and I end up with a list of bugs that need some attention.

Bugs such as allocations returning NULL pointers without checks, memory leaks, duplicate memory frees and uninitialized variables are easy to find with static analyzers and generally just require generally one or two line fixes.

So what are the overall trends like?

Warnings and error messages from cppcheck have been dropping over time and "portable warnings" have been steadily increasing.  "Portable warnings" are mainly from arithmetic on void * pointers (which GCC handles has byte sized but is not legal C), and these are slowly increasing over time.   Note that there is some variation in the results as I use the latest versions of cppcheck, and occasionally it finds a lot of false positives and then this gets fixed in later versions of cppcheck.

Comparing it to the growth in kernel size the drop overall warning and error message trends from cppcheck aren't so bad considering the kernel has grown by nearly 11% over the time I have been running the static analysis.

Kernel source growth over time

Since each warning or error reported has to be carefully scrutinized to determine if they are false positives (and this takes a lot of effort and time), I've not yet been able determine the exact false positive rates on these stats.  Compared to the actual lines of code, cppcheck is finding ~1 error per 15K lines of source.

It would be interesting to run this analysis on commercial static analyzers such as Coverity and see how the stats compare.  As it stands, cppcheck is doing it's bit in detecting errors and helping engineers to improve code quality.