Files
android_kernel_xiaomi_sm8450/tools/testing/selftests
Eric W. Biederman db86da7cb7 userns: Unbreak the unprivileged remount tests
A security fix in caused the way the unprivileged remount tests were
using user namespaces to break.  Tweak the way user namespaces are
being used so the test works again.

Cc: stable@vger.kernel.org
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2014-12-11 18:07:07 -06:00
..
2014-09-30 00:10:00 -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.