selftests/proc: add PROCMAP_QUERY ioctl tests

Extend existing proc-pid-vm.c tests with PROCMAP_QUERY ioctl() API. Test
a few successful and negative cases, validating querying filtering and
exact v

selftests/proc: add PROCMAP_QUERY ioctl tests

Extend existing proc-pid-vm.c tests with PROCMAP_QUERY ioctl() API. Test
a few successful and negative cases, validating querying filtering and
exact vs next VMA logic works as expected.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrii Nakryiko <[email protected]>
Acked-by: Liam R. Howlett <[email protected]>
Cc: Alexey Dobriyan <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Christian Brauner <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Mike Rapoport (IBM) <[email protected]>
Cc: Suren Baghdasaryan <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

proc: fix PIE proc-empty-vm, proc-pid-vm tests

vsyscall detection code uses direct call to the beginning of
the vsyscall page:

asm ("call %P0" :: "i" (0xffffffffff600000))

It generates "call rel3

proc: fix PIE proc-empty-vm, proc-pid-vm tests

vsyscall detection code uses direct call to the beginning of
the vsyscall page:

asm ("call %P0" :: "i" (0xffffffffff600000))

It generates "call rel32" instruction but it is not relocated if binary
is PIE, so binary segfaults into random userspace address and vsyscall
page status is detected incorrectly.

Do more direct:

asm ("call *%rax")

which doesn't do need any relocaltions.

Mark g_vsyscall as volatile for a good measure, I didn't find instruction
setting it to 0. Now the code is obviously correct:

xor eax, eax
mov rdi, rbp
mov rsi, rbp
mov DWORD PTR [rip+0x2d15], eax # g_vsyscall = 0
mov rax, 0xffffffffff600000
call rax
mov DWORD PTR [rip+0x2d02], 1 # g_vsyscall = 1
mov eax, DWORD PTR ds:0xffffffffff600000
mov DWORD PTR [rip+0x2cf1], 2 # g_vsyscall = 2
mov edi, [rip+0x2ceb] # exit(g_vsyscall)
call exit

Note: fixed proc-empty-vm test oopses 5.19.0-28-generic kernel
but this is separate story.

Link: https://lkml.kernel.org/r/Y7h2xvzKLg36DSq8@p183
Fixes: 5bc73bb3451b9 ("proc: test how it holds up with mapping'less process")
Signed-off-by: Alexey Dobriyan <[email protected]>
Reported-by: Mirsad Goran Todorovac <[email protected]>
Tested-by: Mirsad Goran Todorovac <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

proc: save LOC in vsyscall test

Do one fork in vsyscall detection code and let SIGSEGV handler exit and
carry information to the parent saving LOC.

[[email protected]: redo original patch, delete

proc: save LOC in vsyscall test

Do one fork in vsyscall detection code and let SIGSEGV handler exit and
carry information to the parent saving LOC.

[[email protected]: redo original patch, delete unnecessary variables, minimise code changes]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Alexey Dobriyan <[email protected]>
Signed-off-by: Brian Foster <[email protected]>
Reviewed-by: Brian Foster <[email protected]>
Tested-by: Brian Foster <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

proc: fix test for "vsyscall=xonly" boot option

Booting with vsyscall=xonly results in the following vsyscall VMA:

ffffffffff600000-ffffffffff601000 --xp ... [vsyscall]


Test does read from fixed

proc: fix test for "vsyscall=xonly" boot option

Booting with vsyscall=xonly results in the following vsyscall VMA:

ffffffffff600000-ffffffffff601000 --xp ... [vsyscall]


Test does read from fixed vsyscall address to determine if kernel
supports vsyscall page but it doesn't work because, well, vsyscall
page is execute only.

Fix test by trying to execute from the first byte of the page which
contains gettimeofday() stub. This should work because vsyscall
entry points have stable addresses by design.

Alexey, avoiding parsing .config, /proc/config.gz and
/proc/cmdline at all costs.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Alexey Dobriyan <[email protected]>
Cc: Shuah Khan <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

selftests/proc: fix array_size.cocci warning

Fix the following coccicheck warning:

tools/testing/selftests/proc/proc-pid-vm.c:371:26-27:
WARNING: Use ARRAY_SIZE
tools/testing/selftests/proc/proc-pi

selftests/proc: fix array_size.cocci warning

Fix the following coccicheck warning:

tools/testing/selftests/proc/proc-pid-vm.c:371:26-27:
WARNING: Use ARRAY_SIZE
tools/testing/selftests/proc/proc-pid-vm.c:420:26-27:
WARNING: Use ARRAY_SIZE

It has been tested with gcc (Debian 8.3.0-6) 8.3.0 on x86_64.

Signed-off-by: Guo Zhengkui <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

tools/testing/selftests/proc/proc-pid-vm.c: hide "segfault at ffffffffff600000" dmesg spam

Test tries to access vsyscall page and if it doesn't exist gets SIGSEGV
which can spam into dmesg. However

tools/testing/selftests/proc/proc-pid-vm.c: hide "segfault at ffffffffff600000" dmesg spam

Test tries to access vsyscall page and if it doesn't exist gets SIGSEGV
which can spam into dmesg. However the segfault happens by design.
Handle it and carry information via exit code to parent.

Link: http://lkml.kernel.org/r/20190524181256.GA2260@avx2
Signed-off-by: Alexey Dobriyan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

proc: fixup proc-pid-vm test

Silly sizeof(pointer) vs sizeof(uint8_t[]) bug.

Link: http://lkml.kernel.org/r/20190414123009.GA12971@avx2
Fixes: e483b0208784 ("proc: test /proc/*/maps, smaps, smaps_r

proc: fixup proc-pid-vm test

Silly sizeof(pointer) vs sizeof(uint8_t[]) bug.

Link: http://lkml.kernel.org/r/20190414123009.GA12971@avx2
Fixes: e483b0208784 ("proc: test /proc/*/maps, smaps, smaps_rollup, statm")
Signed-off-by: Alexey Dobriyan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

tools/testing/selftests/proc/proc-pid-vm.c: test with vsyscall in mind

: selftests: proc: proc-pid-vm
: ========================================
: proc-pid-vm: proc-pid-vm.c:277: main: Assertion `rv

tools/testing/selftests/proc/proc-pid-vm.c: test with vsyscall in mind

: selftests: proc: proc-pid-vm
: ========================================
: proc-pid-vm: proc-pid-vm.c:277: main: Assertion `rv == strlen(buf0)' failed.
: Aborted

Because the vsyscall mapping is enabled. Read from vsyscall page to tell
if vsyscall is being used.

Link: http://lkml.kernel.org/r/20190307183204.GA11405@avx2
Link: http://lkml.kernel.org/r/20190219094722.GB28258@shao2-debian
Fixes: 34aab6bec23e7e9 ("proc: test /proc/*/maps, smaps, smaps_rollup, statm")
Signed-off-by: Alexey Dobriyan <[email protected]>
Reported-by: kernel test robot <[email protected]>
Cc: Shuah Khan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

proc: test /proc/*/maps, smaps, smaps_rollup, statm

Start testing VM related fiels found in per-process files.

Do it by jiting small executable which brings its address space to
precisely known sta

proc: test /proc/*/maps, smaps, smaps_rollup, statm

Start testing VM related fiels found in per-process files.

Do it by jiting small executable which brings its address space to
precisely known state, then comparing /proc/*/maps, smaps, smaps_rollup,
and statm files to expected values.

Currently only x86_64 is supported.

[[email protected]: exit correctly in /proc/*/maps test]
Link: http://lkml.kernel.org/r/20190206073659.GB15311@avx2
Link: http://lkml.kernel.org/r/20190203165806.GA14568@avx2
Signed-off-by: Alexey Dobriyan <[email protected]>
Cc: Shuah Khan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...