Re: [PATCH] Documentation: updates for new syscall stub naming convention

2018-04-20 Thread Steven Rostedt 
On Fri, 20 Apr 2018 07:44:25 +0200
Dominik Brodowski  wrote:

> For v4.17-rc1, the naming of syscall stubs changed. Update stack
> traces and similar instances in the documentation to avoid sources
> for confusion.
> 
> Signed-off-by: Dominik Brodowski 

Except that on x86 I don't see any __se_sys_* functions in kallsyms.

# grep _se_sys /proc/kallsyms
# grep _x64_sys /proc/kallsyms | head 
81032ae0 T __x64_sys_arch_prctl
81033400 T __x64_sys_rt_sigreturn
81036ea0 T __x64_sys_iopl
810371d0 T __x64_sys_ioperm
81039090 T __x64_sys_modify_ldt
81039da0 T __x64_sys_mmap
81045060 T __x64_sys_set_thread_area
81045150 T __x64_sys_get_thread_area
810aa450 T __x64_sys_set_tid_address
810ad7c0 T __x64_sys_fork

I'd say leave the documentation alone.

-- Steve

> 
> diff --git a/Documentation/admin-guide/bug-hunting.rst 
> b/Documentation/admin-guide/bug-hunting.rst
> index f278b289e260..cebff8e5c59f 100644
> --- a/Documentation/admin-guide/bug-hunting.rst
> +++ b/Documentation/admin-guide/bug-hunting.rst
> @@ -30,7 +30,7 @@ Kernel bug reports often come with a stack dump like the 
> one below::
>[] ? driver_detach+0x87/0x90
>[] ? bus_remove_driver+0x38/0x90
>[] ? usb_deregister+0x58/0xb0
> -  [] ? SyS_delete_module+0x130/0x1f0
> +  [] ? __se_sys_delete_module+0x130/0x1f0
>[] ? task_work_run+0x64/0x80
>[] ? exit_to_usermode_loop+0x85/0x90
>[] ? do_fast_syscall_32+0x80/0x130
> diff --git a/Documentation/dev-tools/kasan.rst 
> b/Documentation/dev-tools/kasan.rst
> index f7a18f274357..0fe231401ae9 100644
> --- a/Documentation/dev-tools/kasan.rst
> +++ b/Documentation/dev-tools/kasan.rst
> @@ -60,7 +60,7 @@ A typical out of bounds access report looks like this::
>   init_module+0x9/0x47 [test_kasan]
>   do_one_initcall+0x99/0x200
>   load_module+0x2cb3/0x3b20
> - SyS_finit_module+0x76/0x80
> + __se_sys_finit_module+0x76/0x80
>   system_call_fastpath+0x12/0x17
>  INFO: Slab 0xea0001a4ef00 objects=17 used=7 fp=0x8800693bd728 
> flags=0x1004080
>  INFO: Object 0x8800693bc558 @offset=1368 fp=0x8800693bc720
> @@ -101,7 +101,7 @@ A typical out of bounds access report looks like this::
>   [] ? __vunmap+0xec/0x160
>   [] load_module+0x2cb3/0x3b20
>   [] ? m_show+0x240/0x240
> - [] SyS_finit_module+0x76/0x80
> + [] __se_sys_finit_module+0x76/0x80
>   [] system_call_fastpath+0x12/0x17
>  Memory state around the buggy address:
>   8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> diff --git a/Documentation/dev-tools/kcov.rst 
> b/Documentation/dev-tools/kcov.rst
> index c2f6452e38ed..df3f4016137a 100644
> --- a/Documentation/dev-tools/kcov.rst
> +++ b/Documentation/dev-tools/kcov.rst
> @@ -103,7 +103,7 @@ program using kcov:
>  
>  After piping through addr2line output of the program looks as follows::
>  
> -SyS_read
> +__se_sys_read
>  fs/read_write.c:562
>  __fdget_pos
>  fs/file.c:774
> @@ -115,7 +115,7 @@ After piping through addr2line output of the program 
> looks as follows::
>  fs/file.c:760
>  __fdget_pos
>  fs/file.c:784
> -SyS_read
> +__se_sys_read
>  fs/read_write.c:562
>  
>  If a program needs to collect coverage from several threads (independently),
> diff --git a/Documentation/locking/lockstat.txt 
> b/Documentation/locking/lockstat.txt
> index 5786ad2cd5e6..346a67e72671 100644
> --- a/Documentation/locking/lockstat.txt
> +++ b/Documentation/locking/lockstat.txt
> @@ -96,7 +96,7 @@ Look at the current lock statistics:
>  12   >mmap_sem 17  
> [] vm_munmap+0x41/0x80
>  13 ---
>  14   >mmap_sem  1  
> [] dup_mmap+0x2a/0x3f0
> -15   >mmap_sem 60  
> [] SyS_mprotect+0xe9/0x250
> +15   >mmap_sem 60  
> [] __se_sys_mprotect+0xe9/0x250
>  16   >mmap_sem 41  
> [] __do_page_fault+0x1d4/0x510
>  17   >mmap_sem 68  
> [] vm_mmap_pgoff+0x87/0xd0
>  18
> diff --git a/Documentation/trace/histogram.txt 
> b/Documentation/trace/histogram.txt
> index 6e05510afc28..f36784deae99 100644
> --- a/Documentation/trace/histogram.txt
> +++ b/Documentation/trace/histogram.txt
> @@ -598,7 +598,7 @@
>   apparmor_cred_prepare+0x1f/0x50
>   security_prepare_creds+0x16/0x20
>   prepare_creds+0xdf/0x1a0
> - SyS_capset+0xb5/0x200
> + __se_sys_capset+0xb5/0x200
>   system_call_fastpath+0x12/0x6a
>  } hitcount:  1  bytes_req: 32  bytes_alloc: 32
>  .
> @@ -609,7 +609,7 @@
>   i915_gem_execbuffer2+0x6c/0x2c0 [i915]
>

Re: [PATCH] Documentation: updates for new syscall stub naming convention

2018-04-20 Thread Steven Rostedt 
On Fri, 20 Apr 2018 07:44:25 +0200
Dominik Brodowski  wrote:

> For v4.17-rc1, the naming of syscall stubs changed. Update stack
> traces and similar instances in the documentation to avoid sources
> for confusion.
> 
> Signed-off-by: Dominik Brodowski 

Except that on x86 I don't see any __se_sys_* functions in kallsyms.

# grep _se_sys /proc/kallsyms
# grep _x64_sys /proc/kallsyms | head 
81032ae0 T __x64_sys_arch_prctl
81033400 T __x64_sys_rt_sigreturn
81036ea0 T __x64_sys_iopl
810371d0 T __x64_sys_ioperm
81039090 T __x64_sys_modify_ldt
81039da0 T __x64_sys_mmap
81045060 T __x64_sys_set_thread_area
81045150 T __x64_sys_get_thread_area
810aa450 T __x64_sys_set_tid_address
810ad7c0 T __x64_sys_fork

I'd say leave the documentation alone.

-- Steve

> 
> diff --git a/Documentation/admin-guide/bug-hunting.rst 
> b/Documentation/admin-guide/bug-hunting.rst
> index f278b289e260..cebff8e5c59f 100644
> --- a/Documentation/admin-guide/bug-hunting.rst
> +++ b/Documentation/admin-guide/bug-hunting.rst
> @@ -30,7 +30,7 @@ Kernel bug reports often come with a stack dump like the 
> one below::
>[] ? driver_detach+0x87/0x90
>[] ? bus_remove_driver+0x38/0x90
>[] ? usb_deregister+0x58/0xb0
> -  [] ? SyS_delete_module+0x130/0x1f0
> +  [] ? __se_sys_delete_module+0x130/0x1f0
>[] ? task_work_run+0x64/0x80
>[] ? exit_to_usermode_loop+0x85/0x90
>[] ? do_fast_syscall_32+0x80/0x130
> diff --git a/Documentation/dev-tools/kasan.rst 
> b/Documentation/dev-tools/kasan.rst
> index f7a18f274357..0fe231401ae9 100644
> --- a/Documentation/dev-tools/kasan.rst
> +++ b/Documentation/dev-tools/kasan.rst
> @@ -60,7 +60,7 @@ A typical out of bounds access report looks like this::
>   init_module+0x9/0x47 [test_kasan]
>   do_one_initcall+0x99/0x200
>   load_module+0x2cb3/0x3b20
> - SyS_finit_module+0x76/0x80
> + __se_sys_finit_module+0x76/0x80
>   system_call_fastpath+0x12/0x17
>  INFO: Slab 0xea0001a4ef00 objects=17 used=7 fp=0x8800693bd728 
> flags=0x1004080
>  INFO: Object 0x8800693bc558 @offset=1368 fp=0x8800693bc720
> @@ -101,7 +101,7 @@ A typical out of bounds access report looks like this::
>   [] ? __vunmap+0xec/0x160
>   [] load_module+0x2cb3/0x3b20
>   [] ? m_show+0x240/0x240
> - [] SyS_finit_module+0x76/0x80
> + [] __se_sys_finit_module+0x76/0x80
>   [] system_call_fastpath+0x12/0x17
>  Memory state around the buggy address:
>   8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> diff --git a/Documentation/dev-tools/kcov.rst 
> b/Documentation/dev-tools/kcov.rst
> index c2f6452e38ed..df3f4016137a 100644
> --- a/Documentation/dev-tools/kcov.rst
> +++ b/Documentation/dev-tools/kcov.rst
> @@ -103,7 +103,7 @@ program using kcov:
>  
>  After piping through addr2line output of the program looks as follows::
>  
> -SyS_read
> +__se_sys_read
>  fs/read_write.c:562
>  __fdget_pos
>  fs/file.c:774
> @@ -115,7 +115,7 @@ After piping through addr2line output of the program 
> looks as follows::
>  fs/file.c:760
>  __fdget_pos
>  fs/file.c:784
> -SyS_read
> +__se_sys_read
>  fs/read_write.c:562
>  
>  If a program needs to collect coverage from several threads (independently),
> diff --git a/Documentation/locking/lockstat.txt 
> b/Documentation/locking/lockstat.txt
> index 5786ad2cd5e6..346a67e72671 100644
> --- a/Documentation/locking/lockstat.txt
> +++ b/Documentation/locking/lockstat.txt
> @@ -96,7 +96,7 @@ Look at the current lock statistics:
>  12   >mmap_sem 17  
> [] vm_munmap+0x41/0x80
>  13 ---
>  14   >mmap_sem  1  
> [] dup_mmap+0x2a/0x3f0
> -15   >mmap_sem 60  
> [] SyS_mprotect+0xe9/0x250
> +15   >mmap_sem 60  
> [] __se_sys_mprotect+0xe9/0x250
>  16   >mmap_sem 41  
> [] __do_page_fault+0x1d4/0x510
>  17   >mmap_sem 68  
> [] vm_mmap_pgoff+0x87/0xd0
>  18
> diff --git a/Documentation/trace/histogram.txt 
> b/Documentation/trace/histogram.txt
> index 6e05510afc28..f36784deae99 100644
> --- a/Documentation/trace/histogram.txt
> +++ b/Documentation/trace/histogram.txt
> @@ -598,7 +598,7 @@
>   apparmor_cred_prepare+0x1f/0x50
>   security_prepare_creds+0x16/0x20
>   prepare_creds+0xdf/0x1a0
> - SyS_capset+0xb5/0x200
> + __se_sys_capset+0xb5/0x200
>   system_call_fastpath+0x12/0x6a
>  } hitcount:  1  bytes_req: 32  bytes_alloc: 32
>  .
> @@ -609,7 +609,7 @@
>   i915_gem_execbuffer2+0x6c/0x2c0 [i915]
>   drm_ioctl+0x349/0x670 [drm]
>

[PATCH] Documentation: updates for new syscall stub naming convention

2018-04-19 Thread Dominik Brodowski 
For v4.17-rc1, the naming of syscall stubs changed. Update stack
traces and similar instances in the documentation to avoid sources
for confusion.

Signed-off-by: Dominik Brodowski 

diff --git a/Documentation/admin-guide/bug-hunting.rst 
b/Documentation/admin-guide/bug-hunting.rst
index f278b289e260..cebff8e5c59f 100644
--- a/Documentation/admin-guide/bug-hunting.rst
+++ b/Documentation/admin-guide/bug-hunting.rst
@@ -30,7 +30,7 @@ Kernel bug reports often come with a stack dump like the one 
below::
 [] ? driver_detach+0x87/0x90
 [] ? bus_remove_driver+0x38/0x90
 [] ? usb_deregister+0x58/0xb0
-[] ? SyS_delete_module+0x130/0x1f0
+[] ? __se_sys_delete_module+0x130/0x1f0
 [] ? task_work_run+0x64/0x80
 [] ? exit_to_usermode_loop+0x85/0x90
 [] ? do_fast_syscall_32+0x80/0x130
diff --git a/Documentation/dev-tools/kasan.rst 
b/Documentation/dev-tools/kasan.rst
index f7a18f274357..0fe231401ae9 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -60,7 +60,7 @@ A typical out of bounds access report looks like this::
  init_module+0x9/0x47 [test_kasan]
  do_one_initcall+0x99/0x200
  load_module+0x2cb3/0x3b20
- SyS_finit_module+0x76/0x80
+ __se_sys_finit_module+0x76/0x80
  system_call_fastpath+0x12/0x17
 INFO: Slab 0xea0001a4ef00 objects=17 used=7 fp=0x8800693bd728 
flags=0x1004080
 INFO: Object 0x8800693bc558 @offset=1368 fp=0x8800693bc720
@@ -101,7 +101,7 @@ A typical out of bounds access report looks like this::
  [] ? __vunmap+0xec/0x160
  [] load_module+0x2cb3/0x3b20
  [] ? m_show+0x240/0x240
- [] SyS_finit_module+0x76/0x80
+ [] __se_sys_finit_module+0x76/0x80
  [] system_call_fastpath+0x12/0x17
 Memory state around the buggy address:
  8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst
index c2f6452e38ed..df3f4016137a 100644
--- a/Documentation/dev-tools/kcov.rst
+++ b/Documentation/dev-tools/kcov.rst
@@ -103,7 +103,7 @@ program using kcov:
 
 After piping through addr2line output of the program looks as follows::
 
-SyS_read
+__se_sys_read
 fs/read_write.c:562
 __fdget_pos
 fs/file.c:774
@@ -115,7 +115,7 @@ After piping through addr2line output of the program looks 
as follows::
 fs/file.c:760
 __fdget_pos
 fs/file.c:784
-SyS_read
+__se_sys_read
 fs/read_write.c:562
 
 If a program needs to collect coverage from several threads (independently),
diff --git a/Documentation/locking/lockstat.txt 
b/Documentation/locking/lockstat.txt
index 5786ad2cd5e6..346a67e72671 100644
--- a/Documentation/locking/lockstat.txt
+++ b/Documentation/locking/lockstat.txt
@@ -96,7 +96,7 @@ Look at the current lock statistics:
 12   >mmap_sem 17  
[] vm_munmap+0x41/0x80
 13 ---
 14   >mmap_sem  1  
[] dup_mmap+0x2a/0x3f0
-15   >mmap_sem 60  
[] SyS_mprotect+0xe9/0x250
+15   >mmap_sem 60  
[] __se_sys_mprotect+0xe9/0x250
 16   >mmap_sem 41  
[] __do_page_fault+0x1d4/0x510
 17   >mmap_sem 68  
[] vm_mmap_pgoff+0x87/0xd0
 18
diff --git a/Documentation/trace/histogram.txt 
b/Documentation/trace/histogram.txt
index 6e05510afc28..f36784deae99 100644
--- a/Documentation/trace/histogram.txt
+++ b/Documentation/trace/histogram.txt
@@ -598,7 +598,7 @@
  apparmor_cred_prepare+0x1f/0x50
  security_prepare_creds+0x16/0x20
  prepare_creds+0xdf/0x1a0
- SyS_capset+0xb5/0x200
+ __se_sys_capset+0xb5/0x200
  system_call_fastpath+0x12/0x6a
 } hitcount:  1  bytes_req: 32  bytes_alloc: 32
 .
@@ -609,7 +609,7 @@
  i915_gem_execbuffer2+0x6c/0x2c0 [i915]
  drm_ioctl+0x349/0x670 [drm]
  do_vfs_ioctl+0x2f0/0x4f0
- SyS_ioctl+0x81/0xa0
+ __se_sys_ioctl+0x81/0xa0
  system_call_fastpath+0x12/0x6a
 } hitcount:  17726  bytes_req:   13944120  bytes_alloc:   19593808
 { stacktrace:
@@ -618,7 +618,7 @@
  load_elf_binary+0x102/0x1650
  search_binary_handler+0x97/0x1d0
  do_execveat_common.isra.34+0x551/0x6e0
- SyS_execve+0x3a/0x50
+ __se_sys_execve+0x3a/0x50
  return_from_execve+0x0/0x23
 } hitcount:  33348  bytes_req:   17152128  bytes_alloc:   20226048
 { stacktrace:
@@ -629,7 +629,7 @@
  path_openat+0x31/0x5f0
  do_filp_open+0x3a/0x90
  do_sys_open+0x128/0x220
- SyS_open+0x1e/0x20
+ __se_sys_open+0x1e/0x20
  system_call_fastpath+0x12/0x6a
 } hitcount:4766422  bytes_req:

[PATCH] Documentation: updates for new syscall stub naming convention

2018-04-19 Thread Dominik Brodowski 
For v4.17-rc1, the naming of syscall stubs changed. Update stack
traces and similar instances in the documentation to avoid sources
for confusion.

Signed-off-by: Dominik Brodowski 

diff --git a/Documentation/admin-guide/bug-hunting.rst 
b/Documentation/admin-guide/bug-hunting.rst
index f278b289e260..cebff8e5c59f 100644
--- a/Documentation/admin-guide/bug-hunting.rst
+++ b/Documentation/admin-guide/bug-hunting.rst
@@ -30,7 +30,7 @@ Kernel bug reports often come with a stack dump like the one 
below::
 [] ? driver_detach+0x87/0x90
 [] ? bus_remove_driver+0x38/0x90
 [] ? usb_deregister+0x58/0xb0
-[] ? SyS_delete_module+0x130/0x1f0
+[] ? __se_sys_delete_module+0x130/0x1f0
 [] ? task_work_run+0x64/0x80
 [] ? exit_to_usermode_loop+0x85/0x90
 [] ? do_fast_syscall_32+0x80/0x130
diff --git a/Documentation/dev-tools/kasan.rst 
b/Documentation/dev-tools/kasan.rst
index f7a18f274357..0fe231401ae9 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -60,7 +60,7 @@ A typical out of bounds access report looks like this::
  init_module+0x9/0x47 [test_kasan]
  do_one_initcall+0x99/0x200
  load_module+0x2cb3/0x3b20
- SyS_finit_module+0x76/0x80
+ __se_sys_finit_module+0x76/0x80
  system_call_fastpath+0x12/0x17
 INFO: Slab 0xea0001a4ef00 objects=17 used=7 fp=0x8800693bd728 
flags=0x1004080
 INFO: Object 0x8800693bc558 @offset=1368 fp=0x8800693bc720
@@ -101,7 +101,7 @@ A typical out of bounds access report looks like this::
  [] ? __vunmap+0xec/0x160
  [] load_module+0x2cb3/0x3b20
  [] ? m_show+0x240/0x240
- [] SyS_finit_module+0x76/0x80
+ [] __se_sys_finit_module+0x76/0x80
  [] system_call_fastpath+0x12/0x17
 Memory state around the buggy address:
  8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst
index c2f6452e38ed..df3f4016137a 100644
--- a/Documentation/dev-tools/kcov.rst
+++ b/Documentation/dev-tools/kcov.rst
@@ -103,7 +103,7 @@ program using kcov:
 
 After piping through addr2line output of the program looks as follows::
 
-SyS_read
+__se_sys_read
 fs/read_write.c:562
 __fdget_pos
 fs/file.c:774
@@ -115,7 +115,7 @@ After piping through addr2line output of the program looks 
as follows::
 fs/file.c:760
 __fdget_pos
 fs/file.c:784
-SyS_read
+__se_sys_read
 fs/read_write.c:562
 
 If a program needs to collect coverage from several threads (independently),
diff --git a/Documentation/locking/lockstat.txt 
b/Documentation/locking/lockstat.txt
index 5786ad2cd5e6..346a67e72671 100644
--- a/Documentation/locking/lockstat.txt
+++ b/Documentation/locking/lockstat.txt
@@ -96,7 +96,7 @@ Look at the current lock statistics:
 12   >mmap_sem 17  
[] vm_munmap+0x41/0x80
 13 ---
 14   >mmap_sem  1  
[] dup_mmap+0x2a/0x3f0
-15   >mmap_sem 60  
[] SyS_mprotect+0xe9/0x250
+15   >mmap_sem 60  
[] __se_sys_mprotect+0xe9/0x250
 16   >mmap_sem 41  
[] __do_page_fault+0x1d4/0x510
 17   >mmap_sem 68  
[] vm_mmap_pgoff+0x87/0xd0
 18
diff --git a/Documentation/trace/histogram.txt 
b/Documentation/trace/histogram.txt
index 6e05510afc28..f36784deae99 100644
--- a/Documentation/trace/histogram.txt
+++ b/Documentation/trace/histogram.txt
@@ -598,7 +598,7 @@
  apparmor_cred_prepare+0x1f/0x50
  security_prepare_creds+0x16/0x20
  prepare_creds+0xdf/0x1a0
- SyS_capset+0xb5/0x200
+ __se_sys_capset+0xb5/0x200
  system_call_fastpath+0x12/0x6a
 } hitcount:  1  bytes_req: 32  bytes_alloc: 32
 .
@@ -609,7 +609,7 @@
  i915_gem_execbuffer2+0x6c/0x2c0 [i915]
  drm_ioctl+0x349/0x670 [drm]
  do_vfs_ioctl+0x2f0/0x4f0
- SyS_ioctl+0x81/0xa0
+ __se_sys_ioctl+0x81/0xa0
  system_call_fastpath+0x12/0x6a
 } hitcount:  17726  bytes_req:   13944120  bytes_alloc:   19593808
 { stacktrace:
@@ -618,7 +618,7 @@
  load_elf_binary+0x102/0x1650
  search_binary_handler+0x97/0x1d0
  do_execveat_common.isra.34+0x551/0x6e0
- SyS_execve+0x3a/0x50
+ __se_sys_execve+0x3a/0x50
  return_from_execve+0x0/0x23
 } hitcount:  33348  bytes_req:   17152128  bytes_alloc:   20226048
 { stacktrace:
@@ -629,7 +629,7 @@
  path_openat+0x31/0x5f0
  do_filp_open+0x3a/0x90
  do_sys_open+0x128/0x220
- SyS_open+0x1e/0x20
+ __se_sys_open+0x1e/0x20
  system_call_fastpath+0x12/0x6a
 } hitcount:4766422  bytes_req:9532844  bytes_alloc: