~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

TOMOYO Linux Cross Reference
Linux/tools/testing/selftests/arm64/signal/README

Version: ~ [ linux-6.12-rc7 ] ~ [ linux-6.11.7 ] ~ [ linux-6.10.14 ] ~ [ linux-6.9.12 ] ~ [ linux-6.8.12 ] ~ [ linux-6.7.12 ] ~ [ linux-6.6.60 ] ~ [ linux-6.5.13 ] ~ [ linux-6.4.16 ] ~ [ linux-6.3.13 ] ~ [ linux-6.2.16 ] ~ [ linux-6.1.116 ] ~ [ linux-6.0.19 ] ~ [ linux-5.19.17 ] ~ [ linux-5.18.19 ] ~ [ linux-5.17.15 ] ~ [ linux-5.16.20 ] ~ [ linux-5.15.171 ] ~ [ linux-5.14.21 ] ~ [ linux-5.13.19 ] ~ [ linux-5.12.19 ] ~ [ linux-5.11.22 ] ~ [ linux-5.10.229 ] ~ [ linux-5.9.16 ] ~ [ linux-5.8.18 ] ~ [ linux-5.7.19 ] ~ [ linux-5.6.19 ] ~ [ linux-5.5.19 ] ~ [ linux-5.4.285 ] ~ [ linux-5.3.18 ] ~ [ linux-5.2.21 ] ~ [ linux-5.1.21 ] ~ [ linux-5.0.21 ] ~ [ linux-4.20.17 ] ~ [ linux-4.19.323 ] ~ [ linux-4.18.20 ] ~ [ linux-4.17.19 ] ~ [ linux-4.16.18 ] ~ [ linux-4.15.18 ] ~ [ linux-4.14.336 ] ~ [ linux-4.13.16 ] ~ [ linux-4.12.14 ] ~ [ linux-4.11.12 ] ~ [ linux-4.10.17 ] ~ [ linux-4.9.337 ] ~ [ linux-4.4.302 ] ~ [ linux-3.10.108 ] ~ [ linux-2.6.32.71 ] ~ [ linux-2.6.0 ] ~ [ linux-2.4.37.11 ] ~ [ unix-v6-master ] ~ [ ccs-tools-1.8.12 ] ~ [ policy-sample ] ~
Architecture: ~ [ i386 ] ~ [ alpha ] ~ [ m68k ] ~ [ mips ] ~ [ ppc ] ~ [ sparc ] ~ [ sparc64 ] ~

Diff markup

Differences between /tools/testing/selftests/arm64/signal/README (Version linux-6.12-rc7) and /tools/testing/selftests/arm64/signal/README (Version linux-5.16.20)


  1 KSelfTest arm64/signal/                             1 KSelfTest arm64/signal/
  2 =======================                             2 =======================
  3                                                     3 
  4 Signals Tests                                       4 Signals Tests
  5 +++++++++++++                                       5 +++++++++++++
  6                                                     6 
  7 - Tests are built around a common main compila      7 - Tests are built around a common main compilation unit: such shared main
  8   enforces a standard sequence of operations n      8   enforces a standard sequence of operations needed to perform a single
  9   signal-test (setup/trigger/run/result/cleanu      9   signal-test (setup/trigger/run/result/cleanup)
 10                                                    10 
 11 - The above mentioned ops are configurable on      11 - The above mentioned ops are configurable on a test-by-test basis: each test
 12   is described (and configured) using the desc     12   is described (and configured) using the descriptor signals.h::struct tdescr
 13                                                    13 
 14 - Each signal testcase is compiled into its ow     14 - Each signal testcase is compiled into its own executable: a separate
 15   executable is used for each test since many      15   executable is used for each test since many tests complete successfully
 16   by receiving some kind of fatal signal from      16   by receiving some kind of fatal signal from the Kernel, so it's safer
 17   to run each test unit in its own standalone      17   to run each test unit in its own standalone process, so as to start each
 18   test from a clean slate.                         18   test from a clean slate.
 19                                                    19 
 20 - New tests can be simply defined in testcases     20 - New tests can be simply defined in testcases/ dir providing a proper struct
 21   tdescr overriding all the defaults we wish t     21   tdescr overriding all the defaults we wish to change (as of now providing a
 22   custom run method is mandatory though)           22   custom run method is mandatory though)
 23                                                    23 
 24 - Signals' test-cases hereafter defined belong     24 - Signals' test-cases hereafter defined belong currently to two
 25   principal families:                              25   principal families:
 26                                                    26 
 27   - 'mangle_' tests: a real signal (SIGUSR1) i     27   - 'mangle_' tests: a real signal (SIGUSR1) is raised and used as a trigger
 28     and then the test case code modifies the s     28     and then the test case code modifies the signal frame from inside the
 29     signal handler itself.                         29     signal handler itself.
 30                                                    30 
 31   - 'fake_sigreturn_' tests: a brand new custo     31   - 'fake_sigreturn_' tests: a brand new custom artificial sigframe structure
 32     is placed on the stack and a sigreturn sys     32     is placed on the stack and a sigreturn syscall is called to simulate a
 33     real signal return. This kind of tests doe     33     real signal return. This kind of tests does not use a trigger usually and
 34     they are just fired using some simple incl     34     they are just fired using some simple included assembly trampoline code.
 35                                                    35 
 36  - Most of these tests are successfully passin     36  - Most of these tests are successfully passing if the process gets killed by
 37    some fatal signal: usually SIGSEGV or SIGBU     37    some fatal signal: usually SIGSEGV or SIGBUS. Since while writing this
 38    kind of tests it is extremely easy in fact      38    kind of tests it is extremely easy in fact to end-up injecting other
 39    unrelated SEGV bugs in the testcases, it be     39    unrelated SEGV bugs in the testcases, it becomes extremely tricky to
 40    be really sure that the tests are really ad     40    be really sure that the tests are really addressing what they are meant
 41    to address and they are not instead falling     41    to address and they are not instead falling apart due to unplanned bugs
 42    in the test code.                               42    in the test code.
 43    In order to alleviate the misery of the lif     43    In order to alleviate the misery of the life of such test-developer, a few
 44    helpers are provided:                           44    helpers are provided:
 45                                                    45 
 46    - a couple of ASSERT_BAD/GOOD_CONTEXT() mac     46    - a couple of ASSERT_BAD/GOOD_CONTEXT() macros to easily parse a ucontext_t
 47      and verify if it is indeed GOOD or BAD (d     47      and verify if it is indeed GOOD or BAD (depending on what we were
 48      expecting), using the same logic/perspect     48      expecting), using the same logic/perspective as in the arm64 Kernel signals
 49      routines.                                     49      routines.
 50                                                    50 
 51    - a sanity mechanism to be used in 'fake_si     51    - a sanity mechanism to be used in 'fake_sigreturn_'-alike tests: enabled by
 52      default it takes care to verify that the      52      default it takes care to verify that the test-execution had at least
 53      successfully progressed up to the stage o     53      successfully progressed up to the stage of triggering the fake sigreturn
 54      call.                                         54      call.
 55                                                    55 
 56   In both cases test results are expected in t     56   In both cases test results are expected in terms of:
 57    - some fatal signal sent by the Kernel to t     57    - some fatal signal sent by the Kernel to the test process
 58   or                                               58   or
 59   - analyzing some final regs state                59   - analyzing some final regs state
                                                      

~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

kernel.org | git.kernel.org | LWN.net | Project Home | SVN repository | Mail admin

Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.

sflogo.php