linux-xiaomi-chiron/tools/testing/selftests
Paul E. McKenney bc51896da2 torture: Check for nul bytes in console output
When starting a new torture run while an old one is still running, both
qemu processes can be outputting to the same console.out file.  This can
cause quite a bit of confusion, so this commit checks for this situation,
which is normally indicated by nul bytes in the console output.  Yes,
if your new run uses up an exact number of blocks of the file, this
check will be ineffective, but the odds are not bad.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
2014-09-07 16:24:49 -07:00
..
breakpoints breakpoint selftests: print failure status instead of cause make error 2012-12-17 17:15:27 -08:00
cpu-hotplug tools: selftests - create a separate hotplug target for full range test 2014-07-11 18:13:06 -07:00
efivarfs efivars: efivarfs_valid_name() should handle pstore syntax 2013-03-06 14:46:04 +00:00
firmware test: add firmware_class loader test 2014-07-17 18:44:19 -07:00
ipc tools/testing/selftests/ipc/msgque.c: improve error handling when not running as root 2014-07-03 09:21:54 -07:00
kcmp tools: fix kcmp_test compile warnings 2014-07-11 18:11:18 -07:00
memfd selftests: add memfd/sealing page-pinning tests 2014-08-08 15:57:31 -07:00
memory-hotplug tools: selftests - create a separate hotplug target for full range test 2014-07-11 18:13:06 -07:00
mount mnt: Add tests for unprivileged remount cases that have found to be faulty 2014-07-31 17:13:15 -07:00
mqueue tools: Fix mqueue Makefile compile linking order 2014-07-11 18:11:18 -07:00
net net: filter: BPF testsuite 2014-05-12 00:23:55 -04:00
powerpc selftests/powerpc: Add test of per-event excludes 2014-07-28 14:11:33 +10:00
ptrace tools/testing/selftests/ptrace/peeksiginfo.c: add PAGE_SIZE definition 2014-08-08 15:57:25 -07:00
rcutorture torture: Check for nul bytes in console output 2014-09-07 16:24:49 -07:00
sysctl tools/testing/selftests/sysctl: validate sysctl_writes_strict 2014-06-06 16:08:13 -07:00
timers tools/testing/selftests: fix uninitialized variable 2013-10-16 21:35:53 -07:00
user test: check copy_to/from_user boundary validation 2014-01-23 16:36:57 -08:00
vm selftests: add .gitignore for vm 2013-07-03 16:08:07 -07:00
Makefile Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace 2014-08-09 17:10:41 -07:00
README.txt tools: selftests - create a separate hotplug target for full range test 2014-07-11 18:13:06 -07:00

Linux Kernel Selftests

The kernel contains a set of "self tests" under the tools/testing/selftests/
directory. These are intended to be small unit tests to exercise individual
code paths in the kernel.

On some systems, hot-plug tests could hang forever waiting for cpu and
memory to be ready to be offlined. A special hot-plug target is created
to run full range of hot-plug tests. In default mode, hot-plug tests run
in safe mode with a limited scope. In limited mode, cpu-hotplug test is
run on a single cpu as opposed to all hotplug capable cpus, and memory
hotplug test is run on 2% of hotplug capable memory instead of 10%.

Running the selftests (hotplug tests are run in limited mode)
=============================================================

To build the tests:

  $ make -C tools/testing/selftests


To run the tests:

  $ make -C tools/testing/selftests run_tests

- note that some tests will require root privileges.

To run only tests targeted for a single subsystem: (including
hotplug targets in limited mode)

  $  make -C tools/testing/selftests TARGETS=cpu-hotplug run_tests

See the top-level tools/testing/selftests/Makefile for the list of all possible
targets.

Running the full range hotplug selftests
========================================

To build the tests:

  $ make -C tools/testing/selftests hotplug

To run the tests:

  $ make -C tools/testing/selftests run_hotplug

- note that some tests will require root privileges.

Contributing new tests
======================

In general, the rules for for selftests are

 * Do as much as you can if you're not root;

 * Don't take too long;

 * Don't break the build on any architecture, and

 * Don't cause the top-level "make run_tests" to fail if your feature is
   unconfigured.