Searched hist:a0968a025c04702427a4aee2c618f451a5098cd8 (Results 1 – 3 of 3) sorted by relevance
| /linux/tools/testing/selftests/powerpc/signal/ |
| H A D | sigreturn_vdso.c | a0968a025c04702427a4aee2c618f451a5098cd8 Wed Mar 04 12:04:02 CET 2020 Michael Ellerman <mpe@ellerman.id.au> selftests/powerpc: Add a test of sigreturn vs VDSO
There's two different paths through the sigreturn code, depending on
whether the VDSO is mapped or not. We recently discovered a bug in the
unmapped case, because it's not commonly used these days.
So add a test that sends itself a signal, then moves the VDSO, takes
another signal and finally unmaps the VDSO before sending itself
another signal. That tests the standard signal path, the code that
handles the VDSO being moved, and also the signal path in the case
where the VDSO is unmapped.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200304110402.6038-1-mpe@ellerman.id.au
|
| H A D | .gitignore | diff a0968a025c04702427a4aee2c618f451a5098cd8 Wed Mar 04 12:04:02 CET 2020 Michael Ellerman <mpe@ellerman.id.au> selftests/powerpc: Add a test of sigreturn vs VDSO
There's two different paths through the sigreturn code, depending on
whether the VDSO is mapped or not. We recently discovered a bug in the
unmapped case, because it's not commonly used these days.
So add a test that sends itself a signal, then moves the VDSO, takes
another signal and finally unmaps the VDSO before sending itself
another signal. That tests the standard signal path, the code that
handles the VDSO being moved, and also the signal path in the case
where the VDSO is unmapped.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200304110402.6038-1-mpe@ellerman.id.au
|
| H A D | Makefile | diff a0968a025c04702427a4aee2c618f451a5098cd8 Wed Mar 04 12:04:02 CET 2020 Michael Ellerman <mpe@ellerman.id.au> selftests/powerpc: Add a test of sigreturn vs VDSO
There's two different paths through the sigreturn code, depending on
whether the VDSO is mapped or not. We recently discovered a bug in the
unmapped case, because it's not commonly used these days.
So add a test that sends itself a signal, then moves the VDSO, takes
another signal and finally unmaps the VDSO before sending itself
another signal. That tests the standard signal path, the code that
handles the VDSO being moved, and also the signal path in the case
where the VDSO is unmapped.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200304110402.6038-1-mpe@ellerman.id.au
|