* Re: [PATCH] syscalls: fix syscall macros for newfstat/newfstatat
From: Rudi Heitbaum @ 2024-08-03 5:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Catalin Marinas, Will Deacon, Huacai Chen, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Andreas Schwab, Florian Weimer,
linux-riscv, linux-arm-kernel, linux-api, Arnd Bergmann,
WANG Xuerui, Masami Hiramatsu (Google), linux-kernel, loongarch
In-Reply-To: <20240801123305.2392874-1-arnd@kernel.org>
On Thu, Aug 01, 2024 at 02:32:33PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The __NR_newfstat and __NR_newfstatat macros accidentally got renamed
> in the conversion to the syscall.tbl format, dropping the 'new' portion
> of the name.
>
> In an unrelated change, the two syscalls are no longer architecture
> specific but are once more defined on all 64-bit architectures, so the
> 'newstat' ABI keyword can be dropped from the table as a simplification.
>
> Fixes: Fixes: 4fe53bf2ba0a ("syscalls: add generic scripts/syscall.tbl")
> Closes: https://lore.kernel.org/lkml/838053e0-b186-4e9f-9668-9a3384a71f23@app.fastmail.com/T/#t
> Reported-by: Florian Weimer <fweimer@redhat.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Hi Arnd,
With this patch to kernel 6.11-rc1 the error whilst compiling gcc-14.2 for
aarch64 with libsanitizer has changed from '__NR_newfstatat' to
'__NR_fstat', so some change, but still fail8ng.
sanitizer_syscall_linux_aarch64.inc:13:23: error: '__NR_newfstatat' was not declared in this scope
13 | #define SYSCALL(name) __NR_ ## name
| ^~~~~
sanitizer_syscall_linux_aarch64.inc:13:23: error: '__NR_fstat' was not declared in this scope
13 | #define SYSCALL(name) __NR_ ## name
| ^~~~~
Regards
Rudi
^ permalink raw reply
* Re: [PATCH] syscalls: fix syscall macros for newfstat/newfstatat
From: Jakub Jelinek @ 2024-08-03 8:00 UTC (permalink / raw)
To: Rudi Heitbaum
Cc: Arnd Bergmann, Catalin Marinas, Will Deacon, Huacai Chen,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Andreas Schwab,
Florian Weimer, linux-riscv, linux-arm-kernel, linux-api,
Arnd Bergmann, WANG Xuerui, Masami Hiramatsu (Google),
linux-kernel, loongarch
In-Reply-To: <Zq28wejX3U9J1_JV@faede8dcc269>
On Sat, Aug 03, 2024 at 05:14:41AM +0000, Rudi Heitbaum wrote:
> With this patch to kernel 6.11-rc1 the error whilst compiling gcc-14.2 for
> aarch64 with libsanitizer has changed from '__NR_newfstatat' to
> '__NR_fstat', so some change, but still fail8ng.
>
> sanitizer_syscall_linux_aarch64.inc:13:23: error: '__NR_newfstatat' was not declared in this scope
> 13 | #define SYSCALL(name) __NR_ ## name
> | ^~~~~
>
> sanitizer_syscall_linux_aarch64.inc:13:23: error: '__NR_fstat' was not declared in this scope
> 13 | #define SYSCALL(name) __NR_ ## name
> | ^~~~~
Probably it would be useful to check
echo '#include <asm/unistd.h>' | gcc -E -dD -xc - | grep '#define __NR_' | sort
for all arches between 6.10 and the latest git, diff them and resolve any
unintended differences.
Jakub
^ permalink raw reply
* Re: [PATCH] syscalls: fix syscall macros for newfstat/newfstatat
From: Arnd Bergmann @ 2024-08-03 8:12 UTC (permalink / raw)
To: Jakub Jelinek, Rudi Heitbaum
Cc: Arnd Bergmann, Catalin Marinas, Will Deacon, Huacai Chen,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Andreas Schwab,
Florian Weimer, linux-riscv, linux-arm-kernel, linux-api,
WANG Xuerui, Masami Hiramatsu, linux-kernel, loongarch
In-Reply-To: <Zq3jqeq6USL066k+@tucnak>
On Sat, Aug 3, 2024, at 10:00, Jakub Jelinek wrote:
> On Sat, Aug 03, 2024 at 05:14:41AM +0000, Rudi Heitbaum wrote:
>> With this patch to kernel 6.11-rc1 the error whilst compiling gcc-14.2 for
>> aarch64 with libsanitizer has changed from '__NR_newfstatat' to
>> '__NR_fstat', so some change, but still fail8ng.
>>
>> sanitizer_syscall_linux_aarch64.inc:13:23: error: '__NR_newfstatat' was not declared in this scope
>> 13 | #define SYSCALL(name) __NR_ ## name
>> | ^~~~~
>>
>> sanitizer_syscall_linux_aarch64.inc:13:23: error: '__NR_fstat' was not declared in this scope
>> 13 | #define SYSCALL(name) __NR_ ## name
>> | ^~~~~
>
Thanks for the report!
Yes, I think I messed it up again by changing both fstatat and
fstat. Our internal names in the kernel are a bit inconsistent
and I failed to realize that only newfstatat uses the "new" name
in the user-facing macro.
> Probably it would be useful to check
> echo '#include <asm/unistd.h>' | gcc -E -dD -xc - | grep '#define __NR_' | sort
> for all arches between 6.10 and the latest git, diff them and resolve any
> unintended differences.
Right, I should have done that before the original series really:
I spent a lot of time validating the kernel's internal changes for
consistency (which found a dozen bugs that were unrelated to my
series) but missed the unintended changes to the external header
contents.
I'll do that now and send another fixup.
Arnd
^ permalink raw reply
* Re: [PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode
From: 潘少 @ 2024-08-03 11:49 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man, linux-api, Michael Kerrisk, panjf2000
In-Reply-To: <4zemhoksplppb35pvpm7cahmaar45hhn3s7tne5pqbgx5bmtg5@jj6hz5yetm4z>
Hi Alejandro,
Sorry to bother you over the weekend, but I haven't seen the patch submitted yet.
Is there something wrong with it?
-----------
Best regards,
Andy Pan
^ permalink raw reply
* Re: [PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode
From: Alejandro Colomar @ 2024-08-03 14:01 UTC (permalink / raw)
To: i; +Cc: linux-man, linux-api, mtk.manpages, Andy Pan
In-Reply-To: <20240801-epoll-et-desc-v5-1-7fcb9260a3b2@andypan.me>
[-- Attachment #1: Type: text/plain, Size: 4802 bytes --]
Hi Andy,
On Thu, Aug 01, 2024 at 11:38:38AM GMT, Andy Pan via B4 Relay wrote:
> From: Andy Pan <i@andypan.me>
>
> For the moment, the edge-triggered epoll generates an event for each
> receipt of a chunk of data, that is to say, epoll_wait() will return
> and tell us a monitored file descriptor is ready whenever there is a
> new activity on that FD since we were last informed about that FD.
> This is not a real _edge_ implementation for epoll, but it's been
> working this way for years and plenty of projects are relying on it
> to eliminate the overhead of one system call of read(2) per wakeup event.
>
> There are several renowned open-source projects relying on this feature
> for notification function (with eventfd): register eventfd with EPOLLET
> and avoid calling read(2) on the eventfd when there is wakeup event (eventfd being written).
> Examples: nginx [1], netty [2], tokio [3], libevent [4], ect. [5]
> These projects are widely used in today's Internet infrastructures.
> Thus, changing this behavior of epoll ET will fundamentally break them
> and cause a significant negative impact.
> Linux has changed it for pipe before [6], breaking some Android libraries,
> which had got "reverted" somehow. [7] [8]
>
> Nevertheless, the paragraph in the manual pages describing this
> characteristic of epoll ET seems ambiguous, I think a more explict
> sentence should be used to clarify it. We're improving the notification
> mechanism for libuv recently by exploiting this feature with eventfd,
> which brings us a significant performance boost. [9]
>
> Therefore, we (as well as the maintainers of nginx, netty, tokio, etc.)
> would have a sense of security to build an enhanced notification function
> based on this feature if there is a guarantee of retaining this implementation
> of epoll ET for the backward compatibility in the man pages.
>
> [1]: https://github.com/nginx/nginx/blob/efc6a217b92985a1ee211b6bb7337cd2f62deb90/src/event/modules/ngx_epoll_module.c#L386-L457
> [2]: https://github.com/netty/netty/pull/9192
> [3]: https://github.com/tokio-rs/mio/blob/309daae21ecb1d46203a7dbc0cf4c80310240cba/src/sys/unix/waker.rs#L111-L143
> [4]: https://github.com/libevent/libevent/blob/525f5d0a14c9c103be750f2ca175328c25505ea4/event.c#L2597-L2614
> [5]: https://github.com/libuv/libuv/pull/4400#issuecomment-2123798748
> [6]: https://lkml.iu.edu/hypermail/linux/kernel/2010.1/04363.html
> [7]: https://github.com/torvalds/linux/commit/3a34b13a88caeb2800ab44a4918f230041b37dd9
> [8]: https://github.com/torvalds/linux/commit/3b844826b6c6affa80755254da322b017358a2f4
> [9]: https://github.com/libuv/libuv/pull/4400#issuecomment-2103232402
>
> Signed-off-by: Andy Pan <i@andypan.me>
> ---
Thanks for the patch. I've applied it, and pushed to my branch:
<https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=da20f7834879cf28ad1d4621f9f1bc421d9c04bf>.
I will take some days before pushing to master, as I'm waiting for a
review of another patch that's before in the queue.
Have a lovely day!
Alex
> Changes in v5:
> - Update the sentence of clarifying the epoll ET
> - Link to v4: https://lore.kernel.org/r/20240731-epoll-et-desc-v4-1-7eb819bdde0d@andypan.me
>
> Changes in v4:
> - Move the added sentence elsewhere to make more sense
> - Link to v3: https://lore.kernel.org/r/20240730-epoll-et-desc-v3-1-6aa81b1c400d@andypan.me
>
> Changes in v3:
> - Updated the git commit description
> - Link to v2: https://lore.kernel.org/r/20240727-epoll-et-desc-v2-1-c99b2ac66775@andypan.me
>
> Changes in v2:
> - Added the git commit description based on feedback
> - Link to v1: https://lore.kernel.org/r/20240727-epoll-et-desc-v1-1-390bafc678b9@andypan.me
> ---
> man/man7/epoll.7 | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/man/man7/epoll.7 b/man/man7/epoll.7
> index 951500131..86e5f8363 100644
> --- a/man/man7/epoll.7
> +++ b/man/man7/epoll.7
> @@ -121,7 +121,8 @@ .SS Level-triggered and edge-triggered
> meanwhile the remote peer might be expecting a response based on the
> data it already sent.
> The reason for this is that edge-triggered mode
> -delivers events only when changes occur on the monitored file descriptor.
> +delivers events only when changes occur on the monitored file descriptor,
> +that is, an event will be generated upon each receipt of a chunk of data.
> So, in step
> .B 5
> the caller might end up waiting for some data that is already present inside
>
> ---
> base-commit: cbc0a111e4dceea2037c51098de33e6bc8c16a5c
> change-id: 20240727-epoll-et-desc-04ea9a590f3b
>
> Best regards,
> --
> Andy Pan <i@andypan.me>
>
>
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode
From: 潘少 @ 2024-08-03 14:15 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man, linux-api, Michael Kerrisk, panjf2000
In-Reply-To: <3d4xkgo7fr6mrlnbcocstjs4ctrh3sutcyrxtgqseiwdjoino5@i3bbqxzii3vx>
Thank you for the updates!
Please also update this email thread after merging this patch, thanks in advance.
Sorry again for interrupting your weekend. Have a great weekend!
-----------
Best regards,
Andy Pan
^ permalink raw reply
* [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: kernel test robot @ 2024-08-04 8:59 UTC (permalink / raw)
To: Jeff Xu
Cc: oe-lkp, lkp, linux-kernel, Andrew Morton, Kees Cook,
Liam R. Howlett, Pedro Falcato, Dave Hansen, Greg Kroah-Hartman,
Guenter Roeck, Jann Horn, Jeff Xu, Jonathan Corbet,
Jorge Lucangeli Obes, Linus Torvalds, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin, oliver.sang
Hello,
kernel test robot noticed a -4.4% regression of stress-ng.pagemove.page_remaps_per_sec on:
commit: 8be7258aad44b5e25977a98db136f677fa6f4370 ("mseal: add mseal syscall")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
testcase: stress-ng
test machine: 64 threads 2 sockets Intel(R) Xeon(R) Gold 6346 CPU @ 3.10GHz (Ice Lake) with 256G memory
parameters:
nr_threads: 100%
testtime: 60s
test: pagemove
cpufreq_governor: performance
In addition to that, the commit also has significant impact on the following tests:
+------------------+---------------------------------------------------------------------------------------------+
| testcase: change | stress-ng: stress-ng.pkey.ops_per_sec -3.6% regression |
| test machine | 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 256G memory |
| test parameters | cpufreq_governor=performance |
| | nr_threads=100% |
| | test=pkey |
| | testtime=60s |
+------------------+---------------------------------------------------------------------------------------------+
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202408041602.caa0372-oliver.sang@intel.com
Details are as below:
-------------------------------------------------------------------------------------------------->
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240804/202408041602.caa0372-oliver.sang@intel.com
=========================================================================================
compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime:
gcc-13/performance/x86_64-rhel-8.3/100%/debian-12-x86_64-20240206.cgz/lkp-icl-2sp7/pagemove/stress-ng/60s
commit:
ff388fe5c4 ("mseal: wire up mseal syscall")
8be7258aad ("mseal: add mseal syscall")
ff388fe5c481d39c 8be7258aad44b5e25977a98db13
---------------- ---------------------------
%stddev %change %stddev
\ | \
41625945 -4.3% 39842322 proc-vmstat.numa_hit
41559175 -4.3% 39774160 proc-vmstat.numa_local
77484314 -4.4% 74105555 proc-vmstat.pgalloc_normal
77205752 -4.4% 73826672 proc-vmstat.pgfree
18361466 -4.2% 17596652 stress-ng.pagemove.ops
306014 -4.2% 293262 stress-ng.pagemove.ops_per_sec
205312 -4.4% 196176 stress-ng.pagemove.page_remaps_per_sec
4961 +1.0% 5013 stress-ng.time.percent_of_cpu_this_job_got
2917 +1.2% 2952 stress-ng.time.system_time
1.07 -6.6% 1.00 perf-stat.i.MPKI
3.354e+10 +3.5% 3.473e+10 perf-stat.i.branch-instructions
1.795e+08 -4.2% 1.719e+08 perf-stat.i.cache-misses
2.376e+08 -4.1% 2.279e+08 perf-stat.i.cache-references
1.13 -3.0% 1.10 perf-stat.i.cpi
1077 +4.3% 1124 perf-stat.i.cycles-between-cache-misses
1.717e+11 +2.7% 1.762e+11 perf-stat.i.instructions
0.88 +3.1% 0.91 perf-stat.i.ipc
1.05 -6.8% 0.97 perf-stat.overall.MPKI
0.25 ± 2% -0.0 0.24 perf-stat.overall.branch-miss-rate%
1.13 -3.0% 1.10 perf-stat.overall.cpi
1084 +4.0% 1127 perf-stat.overall.cycles-between-cache-misses
0.88 +3.1% 0.91 perf-stat.overall.ipc
3.298e+10 +3.5% 3.415e+10 perf-stat.ps.branch-instructions
1.764e+08 -4.3% 1.689e+08 perf-stat.ps.cache-misses
2.336e+08 -4.1% 2.24e+08 perf-stat.ps.cache-references
194.57 -2.4% 189.96 ± 2% perf-stat.ps.cpu-migrations
1.688e+11 +2.7% 1.733e+11 perf-stat.ps.instructions
1.036e+13 +3.0% 1.068e+13 perf-stat.total.instructions
75.12 -1.9 73.22 perf-profile.calltrace.cycles-pp.move_vma.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
36.84 -1.6 35.29 perf-profile.calltrace.cycles-pp.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap.do_syscall_64
24.90 -1.2 23.72 perf-profile.calltrace.cycles-pp.copy_vma.move_vma.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
19.89 -0.9 18.98 perf-profile.calltrace.cycles-pp.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
10.56 ± 2% -0.8 9.78 ± 2% perf-profile.calltrace.cycles-pp.rcu_core.handle_softirqs.run_ksoftirqd.smpboot_thread_fn.kthread
10.56 ± 2% -0.8 9.79 ± 2% perf-profile.calltrace.cycles-pp.handle_softirqs.run_ksoftirqd.smpboot_thread_fn.kthread.ret_from_fork
10.56 ± 2% -0.8 9.79 ± 2% perf-profile.calltrace.cycles-pp.run_ksoftirqd.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
10.57 ± 2% -0.8 9.80 ± 2% perf-profile.calltrace.cycles-pp.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
10.52 ± 2% -0.8 9.75 ± 2% perf-profile.calltrace.cycles-pp.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd.smpboot_thread_fn
10.62 ± 2% -0.8 9.85 ± 2% perf-profile.calltrace.cycles-pp.kthread.ret_from_fork.ret_from_fork_asm
10.62 ± 2% -0.8 9.85 ± 2% perf-profile.calltrace.cycles-pp.ret_from_fork.ret_from_fork_asm
10.62 ± 2% -0.8 9.85 ± 2% perf-profile.calltrace.cycles-pp.ret_from_fork_asm
14.75 -0.7 14.07 perf-profile.calltrace.cycles-pp.vma_merge.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
1.50 -0.6 0.94 perf-profile.calltrace.cycles-pp.mas_find.do_vmi_munmap.move_vma.__do_sys_mremap.do_syscall_64
5.88 ± 2% -0.4 5.47 ± 2% perf-profile.calltrace.cycles-pp.kmem_cache_free.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd
7.80 -0.3 7.47 perf-profile.calltrace.cycles-pp.move_page_tables.move_vma.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
4.55 ± 2% -0.3 4.24 ± 2% perf-profile.calltrace.cycles-pp.__slab_free.kmem_cache_free.rcu_do_batch.rcu_core.handle_softirqs
6.76 -0.3 6.45 perf-profile.calltrace.cycles-pp.vm_area_dup.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
6.15 -0.3 5.86 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.vm_area_dup.__split_vma.do_vmi_align_munmap.do_vmi_munmap
8.22 -0.3 7.93 perf-profile.calltrace.cycles-pp.unmap_region.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
6.12 -0.3 5.87 perf-profile.calltrace.cycles-pp.vma_complete.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
5.74 -0.2 5.50 perf-profile.calltrace.cycles-pp.move_ptes.move_page_tables.move_vma.__do_sys_mremap.do_syscall_64
3.16 ± 2% -0.2 2.94 perf-profile.calltrace.cycles-pp.vm_area_free_rcu_cb.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd
5.50 -0.2 5.28 perf-profile.calltrace.cycles-pp.mas_store_prealloc.vma_complete.__split_vma.do_vmi_align_munmap.do_vmi_munmap
1.36 -0.2 1.14 perf-profile.calltrace.cycles-pp.mas_find.do_vmi_munmap.do_munmap.mremap_to.__do_sys_mremap
5.15 -0.2 4.94 perf-profile.calltrace.cycles-pp.mas_wr_store_entry.mas_store_prealloc.vma_complete.__split_vma.do_vmi_align_munmap
5.51 -0.2 5.31 perf-profile.calltrace.cycles-pp.mas_store_prealloc.vma_merge.copy_vma.move_vma.__do_sys_mremap
5.16 -0.2 4.97 perf-profile.calltrace.cycles-pp.mas_wr_store_entry.mas_store_prealloc.vma_merge.copy_vma.move_vma
2.24 -0.2 2.05 perf-profile.calltrace.cycles-pp.find_vma_prev.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
2.60 ± 2% -0.2 2.42 ± 2% perf-profile.calltrace.cycles-pp.kmem_cache_free.vm_area_free_rcu_cb.rcu_do_batch.rcu_core.handle_softirqs
4.67 -0.2 4.49 perf-profile.calltrace.cycles-pp.mas_wr_node_store.mas_wr_store_entry.mas_store_prealloc.vma_merge.copy_vma
3.41 -0.2 3.23 perf-profile.calltrace.cycles-pp.free_pgtables.unmap_region.do_vmi_align_munmap.do_vmi_munmap.move_vma
3.00 -0.2 2.83 ± 2% perf-profile.calltrace.cycles-pp.anon_vma_clone.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
0.96 -0.2 0.80 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.do_vmi_munmap.do_munmap.mremap_to
4.04 -0.2 3.88 perf-profile.calltrace.cycles-pp.vm_area_dup.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
3.20 ± 2% -0.2 3.04 ± 2% perf-profile.calltrace.cycles-pp.__memcg_slab_post_alloc_hook.kmem_cache_alloc_noprof.vm_area_dup.__split_vma.do_vmi_align_munmap
3.53 -0.1 3.38 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.vm_area_dup.copy_vma.move_vma.__do_sys_mremap
3.40 -0.1 3.26 perf-profile.calltrace.cycles-pp.flush_tlb_mm_range.move_ptes.move_page_tables.move_vma.__do_sys_mremap
2.20 ± 2% -0.1 2.06 ± 2% perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.anon_vma_clone.__split_vma.do_vmi_align_munmap.do_vmi_munmap
1.84 ± 3% -0.1 1.71 ± 3% perf-profile.calltrace.cycles-pp.__memcg_slab_post_alloc_hook.kmem_cache_alloc_noprof.anon_vma_clone.__split_vma.do_vmi_align_munmap
1.78 ± 2% -0.1 1.65 ± 3% perf-profile.calltrace.cycles-pp.vma_prepare.vma_merge.copy_vma.move_vma.__do_sys_mremap
2.69 -0.1 2.56 perf-profile.calltrace.cycles-pp.unlink_anon_vmas.free_pgtables.unmap_region.do_vmi_align_munmap.do_vmi_munmap
1.78 ± 2% -0.1 1.66 ± 2% perf-profile.calltrace.cycles-pp.__slab_free.kmem_cache_free.vm_area_free_rcu_cb.rcu_do_batch.rcu_core
1.36 ± 2% -0.1 1.23 ± 2% perf-profile.calltrace.cycles-pp.rcu_cblist_dequeue.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd
0.95 -0.1 0.83 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.do_vmi_munmap.move_vma.__do_sys_mremap
3.29 -0.1 3.17 perf-profile.calltrace.cycles-pp.mas_store_gfp.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
2.08 -0.1 1.96 perf-profile.calltrace.cycles-pp.mas_preallocate.vma_merge.copy_vma.move_vma.__do_sys_mremap
1.43 ± 3% -0.1 1.32 ± 3% perf-profile.calltrace.cycles-pp.down_write.vma_prepare.vma_merge.copy_vma.move_vma
2.21 -0.1 2.10 perf-profile.calltrace.cycles-pp.mas_preallocate.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
2.47 -0.1 2.36 perf-profile.calltrace.cycles-pp.flush_tlb_func.flush_tlb_mm_range.move_ptes.move_page_tables.move_vma
2.21 -0.1 2.12 perf-profile.calltrace.cycles-pp.native_flush_tlb_one_user.flush_tlb_func.flush_tlb_mm_range.move_ptes.move_page_tables
1.41 -0.1 1.32 perf-profile.calltrace.cycles-pp.mas_alloc_nodes.mas_preallocate.__split_vma.do_vmi_align_munmap.do_vmi_munmap
1.26 -0.1 1.18 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.__split_vma.do_vmi_align_munmap
1.82 -0.1 1.75 perf-profile.calltrace.cycles-pp.vma_link.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
0.71 -0.1 0.63 perf-profile.calltrace.cycles-pp.mas_prev.vma_merge.copy_vma.move_vma.__do_sys_mremap
1.29 -0.1 1.22 perf-profile.calltrace.cycles-pp.mas_wr_store_entry.mas_store_gfp.do_vmi_align_munmap.do_vmi_munmap.move_vma
0.61 -0.1 0.54 perf-profile.calltrace.cycles-pp.mas_prev_setup.mas_prev.vma_merge.copy_vma.move_vma
1.36 -0.1 1.29 perf-profile.calltrace.cycles-pp.kmem_cache_free.unlink_anon_vmas.free_pgtables.unmap_region.do_vmi_align_munmap
1.40 -0.1 1.33 perf-profile.calltrace.cycles-pp.mas_alloc_nodes.mas_preallocate.vma_merge.copy_vma.move_vma
0.70 -0.1 0.64 perf-profile.calltrace.cycles-pp.mas_walk.find_vma_prev.copy_vma.move_vma.__do_sys_mremap
1.23 -0.1 1.17 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.vma_merge.copy_vma
1.66 -0.1 1.60 perf-profile.calltrace.cycles-pp.__get_unmapped_area.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
1.16 -0.1 1.10 perf-profile.calltrace.cycles-pp.anon_vma_clone.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
0.96 -0.1 0.90 perf-profile.calltrace.cycles-pp.__memcg_slab_free_hook.kmem_cache_free.unlink_anon_vmas.free_pgtables.unmap_region
1.14 -0.1 1.08 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.vm_area_dup.__split_vma.do_vmi_align_munmap
0.79 -0.1 0.74 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.__split_vma
1.04 -0.1 1.00 perf-profile.calltrace.cycles-pp.vma_to_resize.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
0.58 -0.0 0.53 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64.mremap
0.61 -0.0 0.56 perf-profile.calltrace.cycles-pp.__memcg_slab_free_hook.kmem_cache_free.vm_area_free_rcu_cb.rcu_do_batch.rcu_core
0.56 -0.0 0.52 perf-profile.calltrace.cycles-pp.mas_find.find_vma_prev.copy_vma.move_vma.__do_sys_mremap
0.57 -0.0 0.53 ± 2% perf-profile.calltrace.cycles-pp.__memcg_slab_free_hook.kmem_cache_free.rcu_do_batch.rcu_core.handle_softirqs
0.78 -0.0 0.74 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.vma_merge
0.88 -0.0 0.84 perf-profile.calltrace.cycles-pp.mtree_load.vma_to_resize.mremap_to.__do_sys_mremap.do_syscall_64
0.70 -0.0 0.66 perf-profile.calltrace.cycles-pp.__call_rcu_common.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
0.68 -0.0 0.64 perf-profile.calltrace.cycles-pp.percpu_counter_add_batch.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
0.68 -0.0 0.64 perf-profile.calltrace.cycles-pp.syscall_return_via_sysret.mremap
0.97 -0.0 0.93 perf-profile.calltrace.cycles-pp.mas_find.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
1.11 -0.0 1.08 perf-profile.calltrace.cycles-pp.clear_bhb_loop.mremap
0.75 -0.0 0.72 perf-profile.calltrace.cycles-pp.allocate_slab.___slab_alloc.kmem_cache_alloc_noprof.vm_area_dup.__split_vma
0.74 -0.0 0.71 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.anon_vma_clone.copy_vma.move_vma.__do_sys_mremap
0.60 ± 2% -0.0 0.57 perf-profile.calltrace.cycles-pp.security_mmap_addr.__get_unmapped_area.mremap_to.__do_sys_mremap.do_syscall_64
0.67 ± 2% -0.0 0.64 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.vm_area_dup.copy_vma.move_vma
0.82 -0.0 0.79 perf-profile.calltrace.cycles-pp.mtree_load.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
0.63 -0.0 0.60 perf-profile.calltrace.cycles-pp.mas_prev_slot.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
0.99 -0.0 0.96 perf-profile.calltrace.cycles-pp.mt_find.vma_merge.copy_vma.move_vma.__do_sys_mremap
0.62 ± 2% -0.0 0.59 perf-profile.calltrace.cycles-pp.get_old_pud.move_page_tables.move_vma.__do_sys_mremap.do_syscall_64
0.87 -0.0 0.84 perf-profile.calltrace.cycles-pp.userfaultfd_unmap_complete.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
0.78 -0.0 0.75 perf-profile.calltrace.cycles-pp.mas_store_prealloc.vma_link.copy_vma.move_vma.__do_sys_mremap
0.64 -0.0 0.62 perf-profile.calltrace.cycles-pp.mas_preallocate.vma_link.copy_vma.move_vma.__do_sys_mremap
0.90 -0.0 0.87 perf-profile.calltrace.cycles-pp.mtree_load.vma_merge.copy_vma.move_vma.__do_sys_mremap
0.54 -0.0 0.52 perf-profile.calltrace.cycles-pp.__pte_offset_map_lock.move_ptes.move_page_tables.move_vma.__do_sys_mremap
1.04 +0.0 1.08 perf-profile.calltrace.cycles-pp.zap_pte_range.zap_pmd_range.unmap_page_range.unmap_vmas.unmap_region
0.76 +0.1 0.83 perf-profile.calltrace.cycles-pp.__madvise
0.63 +0.1 0.70 perf-profile.calltrace.cycles-pp.__x64_sys_madvise.do_syscall_64.entry_SYSCALL_64_after_hwframe.__madvise
0.62 +0.1 0.70 perf-profile.calltrace.cycles-pp.do_madvise.__x64_sys_madvise.do_syscall_64.entry_SYSCALL_64_after_hwframe.__madvise
0.66 +0.1 0.74 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.__madvise
0.66 +0.1 0.74 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.__madvise
87.74 +0.7 88.45 perf-profile.calltrace.cycles-pp.mremap
0.00 +0.9 0.86 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.can_modify_mm.do_vmi_munmap.do_munmap
0.00 +0.9 0.86 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.can_modify_mm.mremap_to.__do_sys_mremap
84.88 +0.9 85.77 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.mremap
84.73 +0.9 85.62 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
0.00 +0.9 0.92 ± 2% perf-profile.calltrace.cycles-pp.mas_walk.mas_find.can_modify_mm.do_vmi_munmap.move_vma
83.84 +0.9 84.78 perf-profile.calltrace.cycles-pp.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
0.00 +1.1 1.06 perf-profile.calltrace.cycles-pp.mas_find.can_modify_mm.mremap_to.__do_sys_mremap.do_syscall_64
0.00 +1.2 1.21 perf-profile.calltrace.cycles-pp.mas_find.can_modify_mm.do_vmi_munmap.do_munmap.mremap_to
2.07 +1.5 3.55 perf-profile.calltrace.cycles-pp.do_munmap.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
1.58 +1.5 3.07 perf-profile.calltrace.cycles-pp.do_vmi_munmap.do_munmap.mremap_to.__do_sys_mremap.do_syscall_64
0.00 +1.5 1.52 perf-profile.calltrace.cycles-pp.mas_find.can_modify_mm.do_vmi_munmap.move_vma.__do_sys_mremap
0.00 +1.6 1.57 perf-profile.calltrace.cycles-pp.can_modify_mm.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
0.00 +1.7 1.72 perf-profile.calltrace.cycles-pp.can_modify_mm.do_vmi_munmap.do_munmap.mremap_to.__do_sys_mremap
0.00 +2.0 2.01 perf-profile.calltrace.cycles-pp.can_modify_mm.do_vmi_munmap.move_vma.__do_sys_mremap.do_syscall_64
5.39 +2.9 8.32 perf-profile.calltrace.cycles-pp.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
75.29 -1.9 73.37 perf-profile.children.cycles-pp.move_vma
37.06 -1.6 35.50 perf-profile.children.cycles-pp.do_vmi_align_munmap
24.98 -1.2 23.80 perf-profile.children.cycles-pp.copy_vma
19.99 -1.0 19.02 perf-profile.children.cycles-pp.handle_softirqs
19.97 -1.0 19.00 perf-profile.children.cycles-pp.rcu_core
19.95 -1.0 18.98 perf-profile.children.cycles-pp.rcu_do_batch
19.98 -0.9 19.06 perf-profile.children.cycles-pp.__split_vma
17.55 -0.8 16.76 perf-profile.children.cycles-pp.kmem_cache_free
10.56 ± 2% -0.8 9.79 ± 2% perf-profile.children.cycles-pp.run_ksoftirqd
10.57 ± 2% -0.8 9.80 ± 2% perf-profile.children.cycles-pp.smpboot_thread_fn
15.38 -0.8 14.62 perf-profile.children.cycles-pp.kmem_cache_alloc_noprof
10.62 ± 2% -0.8 9.85 ± 2% perf-profile.children.cycles-pp.kthread
10.62 ± 2% -0.8 9.86 ± 2% perf-profile.children.cycles-pp.ret_from_fork
10.62 ± 2% -0.8 9.86 ± 2% perf-profile.children.cycles-pp.ret_from_fork_asm
15.14 -0.7 14.44 perf-profile.children.cycles-pp.vma_merge
12.08 -0.5 11.55 perf-profile.children.cycles-pp.__slab_free
12.11 -0.5 11.62 perf-profile.children.cycles-pp.mas_wr_store_entry
10.86 -0.5 10.39 perf-profile.children.cycles-pp.vm_area_dup
11.89 -0.5 11.44 perf-profile.children.cycles-pp.mas_store_prealloc
8.49 -0.4 8.06 perf-profile.children.cycles-pp.__memcg_slab_post_alloc_hook
9.88 -0.4 9.49 perf-profile.children.cycles-pp.mas_wr_node_store
7.91 -0.3 7.58 perf-profile.children.cycles-pp.move_page_tables
6.06 -0.3 5.78 perf-profile.children.cycles-pp.vm_area_free_rcu_cb
8.28 -0.3 8.00 perf-profile.children.cycles-pp.unmap_region
6.69 -0.3 6.42 perf-profile.children.cycles-pp.vma_complete
5.06 -0.3 4.80 perf-profile.children.cycles-pp.mas_preallocate
5.82 -0.2 5.57 perf-profile.children.cycles-pp.move_ptes
4.24 -0.2 4.01 perf-profile.children.cycles-pp.anon_vma_clone
3.50 -0.2 3.30 perf-profile.children.cycles-pp.down_write
2.44 -0.2 2.25 perf-profile.children.cycles-pp.find_vma_prev
3.46 -0.2 3.28 perf-profile.children.cycles-pp.___slab_alloc
3.45 -0.2 3.27 perf-profile.children.cycles-pp.free_pgtables
2.54 -0.2 2.37 perf-profile.children.cycles-pp.rcu_cblist_dequeue
3.35 -0.2 3.18 perf-profile.children.cycles-pp.__memcg_slab_free_hook
2.93 -0.2 2.78 perf-profile.children.cycles-pp.mas_alloc_nodes
2.28 ± 2% -0.2 2.12 ± 2% perf-profile.children.cycles-pp.vma_prepare
3.46 -0.1 3.32 perf-profile.children.cycles-pp.flush_tlb_mm_range
3.41 -0.1 3.27 ± 2% perf-profile.children.cycles-pp.mod_objcg_state
2.76 -0.1 2.63 perf-profile.children.cycles-pp.unlink_anon_vmas
3.41 -0.1 3.28 perf-profile.children.cycles-pp.mas_store_gfp
2.21 -0.1 2.09 perf-profile.children.cycles-pp.__cond_resched
2.04 -0.1 1.94 perf-profile.children.cycles-pp.allocate_slab
2.10 -0.1 2.00 perf-profile.children.cycles-pp.__call_rcu_common
2.51 -0.1 2.40 perf-profile.children.cycles-pp.flush_tlb_func
1.04 -0.1 0.94 perf-profile.children.cycles-pp.mas_prev
2.71 -0.1 2.61 perf-profile.children.cycles-pp.mtree_load
2.23 -0.1 2.14 perf-profile.children.cycles-pp.native_flush_tlb_one_user
0.22 ± 5% -0.1 0.13 ± 13% perf-profile.children.cycles-pp.vm_stat_account
0.95 -0.1 0.87 perf-profile.children.cycles-pp.mas_prev_setup
1.65 -0.1 1.57 perf-profile.children.cycles-pp.mas_wr_walk
1.84 -0.1 1.76 perf-profile.children.cycles-pp.up_write
1.27 -0.1 1.20 perf-profile.children.cycles-pp.mas_prev_slot
1.84 -0.1 1.77 perf-profile.children.cycles-pp.vma_link
1.39 -0.1 1.32 perf-profile.children.cycles-pp.shuffle_freelist
0.96 -0.1 0.90 ± 2% perf-profile.children.cycles-pp.rcu_all_qs
0.86 -0.1 0.80 perf-profile.children.cycles-pp._raw_spin_lock_irqsave
1.70 -0.1 1.64 perf-profile.children.cycles-pp.__get_unmapped_area
0.34 ± 3% -0.1 0.29 ± 5% perf-profile.children.cycles-pp.security_vm_enough_memory_mm
0.60 -0.0 0.55 perf-profile.children.cycles-pp.entry_SYSCALL_64
0.92 -0.0 0.87 perf-profile.children.cycles-pp.percpu_counter_add_batch
1.07 -0.0 1.02 perf-profile.children.cycles-pp.vma_to_resize
1.59 -0.0 1.54 perf-profile.children.cycles-pp.mas_update_gap
0.44 ± 2% -0.0 0.40 ± 2% perf-profile.children.cycles-pp.native_queued_spin_lock_slowpath
0.70 -0.0 0.66 perf-profile.children.cycles-pp.syscall_return_via_sysret
1.13 -0.0 1.09 perf-profile.children.cycles-pp.mt_find
0.20 ± 6% -0.0 0.17 ± 9% perf-profile.children.cycles-pp.cap_vm_enough_memory
0.99 -0.0 0.95 perf-profile.children.cycles-pp.mas_pop_node
0.63 ± 2% -0.0 0.59 perf-profile.children.cycles-pp.security_mmap_addr
0.62 -0.0 0.59 perf-profile.children.cycles-pp.__put_partials
1.17 -0.0 1.14 perf-profile.children.cycles-pp.clear_bhb_loop
0.46 -0.0 0.43 ± 2% perf-profile.children.cycles-pp.__alloc_pages_noprof
0.44 -0.0 0.41 ± 2% perf-profile.children.cycles-pp.get_page_from_freelist
0.90 -0.0 0.87 perf-profile.children.cycles-pp.userfaultfd_unmap_complete
0.64 ± 2% -0.0 0.62 perf-profile.children.cycles-pp.get_old_pud
1.07 -0.0 1.05 perf-profile.children.cycles-pp.mas_leaf_max_gap
0.22 ± 3% -0.0 0.20 ± 2% perf-profile.children.cycles-pp.__rmqueue_pcplist
0.55 -0.0 0.53 perf-profile.children.cycles-pp.refill_obj_stock
0.25 -0.0 0.23 ± 3% perf-profile.children.cycles-pp.rmqueue
0.48 -0.0 0.45 perf-profile.children.cycles-pp.mremap_userfaultfd_prep
0.33 -0.0 0.30 perf-profile.children.cycles-pp.free_unref_page
0.46 -0.0 0.44 perf-profile.children.cycles-pp.setup_object
0.21 ± 3% -0.0 0.19 ± 2% perf-profile.children.cycles-pp.rmqueue_bulk
0.31 ± 3% -0.0 0.29 perf-profile.children.cycles-pp.__vm_enough_memory
0.40 -0.0 0.38 perf-profile.children.cycles-pp.entry_SYSRETQ_unsafe_stack
0.36 -0.0 0.35 perf-profile.children.cycles-pp.madvise_vma_behavior
0.54 -0.0 0.53 ± 2% perf-profile.children.cycles-pp.mas_wr_end_piv
0.46 -0.0 0.44 ± 2% perf-profile.children.cycles-pp.rcu_segcblist_enqueue
0.34 -0.0 0.32 ± 2% perf-profile.children.cycles-pp.mas_destroy
0.28 -0.0 0.26 ± 3% perf-profile.children.cycles-pp.mas_wr_store_setup
0.30 -0.0 0.28 perf-profile.children.cycles-pp.pte_offset_map_nolock
0.19 -0.0 0.18 ± 2% perf-profile.children.cycles-pp.__thp_vma_allowable_orders
0.08 ± 4% -0.0 0.07 perf-profile.children.cycles-pp.ksm_madvise
0.17 -0.0 0.16 perf-profile.children.cycles-pp.get_any_partial
0.08 -0.0 0.07 perf-profile.children.cycles-pp.syscall_exit_to_user_mode_prepare
0.45 +0.0 0.47 perf-profile.children.cycles-pp._raw_spin_lock
1.10 +0.0 1.14 perf-profile.children.cycles-pp.zap_pte_range
0.78 +0.1 0.85 perf-profile.children.cycles-pp.__madvise
0.63 +0.1 0.70 perf-profile.children.cycles-pp.__x64_sys_madvise
0.62 +0.1 0.70 perf-profile.children.cycles-pp.do_madvise
0.00 +0.1 0.09 ± 4% perf-profile.children.cycles-pp.can_modify_mm_madv
1.32 +0.1 1.46 perf-profile.children.cycles-pp.mas_next_slot
88.13 +0.7 88.83 perf-profile.children.cycles-pp.mremap
83.94 +0.9 84.88 perf-profile.children.cycles-pp.__do_sys_mremap
86.06 +0.9 87.00 perf-profile.children.cycles-pp.entry_SYSCALL_64_after_hwframe
85.56 +1.0 86.54 perf-profile.children.cycles-pp.do_syscall_64
40.49 +1.4 41.90 perf-profile.children.cycles-pp.do_vmi_munmap
2.10 +1.5 3.57 perf-profile.children.cycles-pp.do_munmap
3.62 +2.3 5.90 perf-profile.children.cycles-pp.mas_walk
5.44 +2.9 8.38 perf-profile.children.cycles-pp.mremap_to
5.30 +3.1 8.39 perf-profile.children.cycles-pp.mas_find
0.00 +5.4 5.40 perf-profile.children.cycles-pp.can_modify_mm
11.46 -0.5 10.96 perf-profile.self.cycles-pp.__slab_free
4.30 -0.2 4.08 perf-profile.self.cycles-pp.__memcg_slab_post_alloc_hook
2.51 -0.2 2.34 perf-profile.self.cycles-pp.rcu_cblist_dequeue
2.41 ± 2% -0.2 2.25 perf-profile.self.cycles-pp.down_write
2.21 -0.1 2.11 perf-profile.self.cycles-pp.native_flush_tlb_one_user
2.37 -0.1 2.28 perf-profile.self.cycles-pp.mtree_load
1.60 -0.1 1.51 perf-profile.self.cycles-pp.__memcg_slab_free_hook
0.18 ± 3% -0.1 0.10 ± 15% perf-profile.self.cycles-pp.vm_stat_account
1.25 -0.1 1.18 perf-profile.self.cycles-pp.move_vma
1.76 -0.1 1.69 perf-profile.self.cycles-pp.mod_objcg_state
1.42 -0.1 1.35 ± 2% perf-profile.self.cycles-pp.__call_rcu_common
1.41 -0.1 1.34 perf-profile.self.cycles-pp.mas_wr_walk
1.52 -0.1 1.46 perf-profile.self.cycles-pp.up_write
1.02 -0.1 0.95 perf-profile.self.cycles-pp.mas_prev_slot
0.96 -0.1 0.90 ± 2% perf-profile.self.cycles-pp.vm_area_free_rcu_cb
1.50 -0.1 1.45 perf-profile.self.cycles-pp.kmem_cache_free
0.69 ± 3% -0.1 0.64 ± 2% perf-profile.self.cycles-pp.rcu_all_qs
1.14 ± 2% -0.1 1.09 perf-profile.self.cycles-pp.shuffle_freelist
1.10 -0.1 1.05 perf-profile.self.cycles-pp.__cond_resched
1.40 -0.0 1.35 perf-profile.self.cycles-pp.do_vmi_align_munmap
0.99 -0.0 0.94 perf-profile.self.cycles-pp.mas_preallocate
0.88 -0.0 0.83 perf-profile.self.cycles-pp.___slab_alloc
0.55 -0.0 0.50 perf-profile.self.cycles-pp.mremap_to
0.98 -0.0 0.93 perf-profile.self.cycles-pp.move_ptes
0.78 -0.0 0.74 perf-profile.self.cycles-pp.percpu_counter_add_batch
0.21 ± 2% -0.0 0.18 ± 2% perf-profile.self.cycles-pp.entry_SYSCALL_64
0.44 ± 2% -0.0 0.40 ± 2% perf-profile.self.cycles-pp.native_queued_spin_lock_slowpath
0.92 -0.0 0.89 perf-profile.self.cycles-pp.mas_store_gfp
0.86 -0.0 0.82 perf-profile.self.cycles-pp.mas_pop_node
0.50 -0.0 0.46 perf-profile.self.cycles-pp.entry_SYSCALL_64_after_hwframe
1.15 -0.0 1.12 perf-profile.self.cycles-pp.clear_bhb_loop
1.14 -0.0 1.11 perf-profile.self.cycles-pp.vma_merge
0.66 -0.0 0.63 perf-profile.self.cycles-pp.__split_vma
0.16 ± 6% -0.0 0.13 ± 7% perf-profile.self.cycles-pp.cap_vm_enough_memory
0.82 -0.0 0.79 perf-profile.self.cycles-pp.mas_wr_store_entry
0.54 ± 2% -0.0 0.52 perf-profile.self.cycles-pp.get_old_pud
0.43 -0.0 0.40 perf-profile.self.cycles-pp.do_munmap
0.51 ± 2% -0.0 0.48 ± 2% perf-profile.self.cycles-pp.security_mmap_addr
0.50 -0.0 0.48 perf-profile.self.cycles-pp.refill_obj_stock
0.24 -0.0 0.22 perf-profile.self.cycles-pp.mas_prev
0.71 -0.0 0.69 perf-profile.self.cycles-pp.unmap_page_range
0.48 -0.0 0.45 perf-profile.self.cycles-pp.find_vma_prev
0.42 -0.0 0.40 perf-profile.self.cycles-pp._raw_spin_lock_irqsave
0.66 -0.0 0.64 perf-profile.self.cycles-pp.mas_store_prealloc
0.31 -0.0 0.29 perf-profile.self.cycles-pp.mas_prev_setup
0.43 -0.0 0.41 perf-profile.self.cycles-pp.mas_wr_end_piv
0.78 -0.0 0.76 perf-profile.self.cycles-pp.userfaultfd_unmap_complete
0.28 -0.0 0.26 ± 2% perf-profile.self.cycles-pp.mas_put_in_tree
0.42 -0.0 0.40 perf-profile.self.cycles-pp.mremap_userfaultfd_prep
0.28 -0.0 0.26 perf-profile.self.cycles-pp.free_pgtables
0.39 -0.0 0.37 perf-profile.self.cycles-pp.entry_SYSRETQ_unsafe_stack
0.30 ± 2% -0.0 0.28 perf-profile.self.cycles-pp.zap_pmd_range
0.32 -0.0 0.31 perf-profile.self.cycles-pp.unmap_vmas
0.21 -0.0 0.20 perf-profile.self.cycles-pp.__get_unmapped_area
0.18 ± 2% -0.0 0.17 ± 2% perf-profile.self.cycles-pp.lru_add_drain_cpu
0.06 -0.0 0.05 perf-profile.self.cycles-pp.ksm_madvise
0.45 +0.0 0.46 perf-profile.self.cycles-pp.do_vmi_munmap
0.37 +0.0 0.39 perf-profile.self.cycles-pp._raw_spin_lock
1.06 +0.1 1.18 perf-profile.self.cycles-pp.mas_next_slot
1.50 +0.5 1.97 perf-profile.self.cycles-pp.mas_find
0.00 +1.4 1.35 perf-profile.self.cycles-pp.can_modify_mm
3.13 +2.0 5.13 perf-profile.self.cycles-pp.mas_walk
***************************************************************************************************
lkp-spr-r02: 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 256G memory
=========================================================================================
compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime:
gcc-13/performance/x86_64-rhel-8.3/100%/debian-12-x86_64-20240206.cgz/lkp-spr-r02/pkey/stress-ng/60s
commit:
ff388fe5c4 ("mseal: wire up mseal syscall")
8be7258aad ("mseal: add mseal syscall")
ff388fe5c481d39c 8be7258aad44b5e25977a98db13
---------------- ---------------------------
%stddev %change %stddev
\ | \
10539 -2.5% 10273 vmstat.system.cs
0.28 ± 5% -20.1% 0.22 ± 7% sched_debug.cfs_rq:/.h_nr_running.stddev
1419 ± 7% -15.3% 1202 ± 6% sched_debug.cfs_rq:/.util_avg.max
0.28 ± 6% -18.4% 0.23 ± 8% sched_debug.cpu.nr_running.stddev
8.736e+08 -3.6% 8.423e+08 stress-ng.pkey.ops
14560560 -3.6% 14038795 stress-ng.pkey.ops_per_sec
770.39 ± 4% -5.0% 732.04 stress-ng.time.user_time
244657 ± 3% +5.8% 258782 ± 3% proc-vmstat.nr_slab_unreclaimable
73133541 -2.1% 71588873 proc-vmstat.numa_hit
72873579 -2.1% 71357274 proc-vmstat.numa_local
1.842e+08 -2.5% 1.796e+08 proc-vmstat.pgalloc_normal
1.767e+08 -2.8% 1.717e+08 proc-vmstat.pgfree
1345346 ± 40% -73.1% 362064 ±124% numa-vmstat.node0.nr_inactive_anon
1345340 ± 40% -73.1% 362062 ±124% numa-vmstat.node0.nr_zone_inactive_anon
2420830 ± 14% +35.1% 3270248 ± 16% numa-vmstat.node1.nr_file_pages
2067871 ± 13% +51.5% 3132982 ± 17% numa-vmstat.node1.nr_inactive_anon
191406 ± 17% +33.6% 255808 ± 14% numa-vmstat.node1.nr_mapped
2452 ± 61% +104.4% 5012 ± 35% numa-vmstat.node1.nr_page_table_pages
2067853 ± 13% +51.5% 3132966 ± 17% numa-vmstat.node1.nr_zone_inactive_anon
5379238 ± 40% -73.0% 1453605 ±123% numa-meminfo.node0.Inactive
5379166 ± 40% -73.0% 1453462 ±123% numa-meminfo.node0.Inactive(anon)
8741077 ± 22% -36.7% 5531290 ± 28% numa-meminfo.node0.MemUsed
9651902 ± 13% +35.8% 13105318 ± 16% numa-meminfo.node1.FilePages
8239855 ± 13% +52.4% 12556929 ± 17% numa-meminfo.node1.Inactive
8239712 ± 13% +52.4% 12556853 ± 17% numa-meminfo.node1.Inactive(anon)
761944 ± 18% +34.6% 1025906 ± 14% numa-meminfo.node1.Mapped
11679628 ± 11% +31.2% 15322841 ± 14% numa-meminfo.node1.MemUsed
9874 ± 62% +104.6% 20200 ± 36% numa-meminfo.node1.PageTables
0.74 -4.2% 0.71 perf-stat.i.MPKI
1.245e+11 +2.3% 1.274e+11 perf-stat.i.branch-instructions
0.37 -0.0 0.35 perf-stat.i.branch-miss-rate%
4.359e+08 -2.1% 4.265e+08 perf-stat.i.branch-misses
4.672e+08 -2.6% 4.548e+08 perf-stat.i.cache-misses
7.276e+08 -2.7% 7.082e+08 perf-stat.i.cache-references
1.00 -1.6% 0.98 perf-stat.i.cpi
1364 +2.9% 1404 perf-stat.i.cycles-between-cache-misses
6.392e+11 +1.7% 6.499e+11 perf-stat.i.instructions
1.00 +1.6% 1.02 perf-stat.i.ipc
0.74 -4.3% 0.71 perf-stat.overall.MPKI
0.35 -0.0 0.33 perf-stat.overall.branch-miss-rate%
1.00 -1.6% 0.99 perf-stat.overall.cpi
1356 +2.9% 1395 perf-stat.overall.cycles-between-cache-misses
1.00 +1.6% 1.01 perf-stat.overall.ipc
1.209e+11 +1.9% 1.232e+11 perf-stat.ps.branch-instructions
4.188e+08 -2.6% 4.077e+08 perf-stat.ps.branch-misses
4.585e+08 -3.1% 4.441e+08 perf-stat.ps.cache-misses
7.124e+08 -3.1% 6.901e+08 perf-stat.ps.cache-references
10321 -2.6% 10053 perf-stat.ps.context-switches
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Linus Torvalds @ 2024-08-04 20:32 UTC (permalink / raw)
To: kernel test robot
Cc: Jeff Xu, oe-lkp, lkp, linux-kernel, Andrew Morton, Kees Cook,
Liam R. Howlett, Pedro Falcato, Dave Hansen, Greg Kroah-Hartman,
Guenter Roeck, Jann Horn, Jeff Xu, Jonathan Corbet,
Jorge Lucangeli Obes, Matthew Wilcox, Muhammad Usama Anjum,
Stephen Röttger, Suren Baghdasaryan, Amer Al Shanawany,
Javier Carrasco, Shuah Khan, linux-api, linux-mm, ying.huang,
feng.tang, fengwei.yin
In-Reply-To: <202408041602.caa0372-oliver.sang@intel.com>
On Sun, 4 Aug 2024 at 01:59, kernel test robot <oliver.sang@intel.com> wrote:
>
> kernel test robot noticed a -4.4% regression of stress-ng.pagemove.page_remaps_per_sec on
> commit 8be7258aad44 ("mseal: add mseal syscall")
Ok, it's basically just the vma walk in can_modify_mm():
> 1.06 +0.1 1.18 perf-profile.self.cycles-pp.mas_next_slot
> 1.50 +0.5 1.97 perf-profile.self.cycles-pp.mas_find
> 0.00 +1.4 1.35 perf-profile.self.cycles-pp.can_modify_mm
> 3.13 +2.0 5.13 perf-profile.self.cycles-pp.mas_walk
and looks like it's two different pathways. We have __do_sys_mremap ->
mremap_to -> do_munmap -> do_vmi_munmap -> can_modify_mm for the
destination mapping, but we also have mremap_to() calling
can_modify_mm() directly for the source mapping.
And then do_vmi_munmap() will do it's *own* vma_find() after having
done arch_unmap().
And do_munmap() will obviously do its own vma lookup as part of
calling vma_to_resize().
So it looks like a large portion of this regression is because the
mseal addition just ends up walking the vma list way too much.
Linus
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Pedro Falcato @ 2024-08-05 13:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: kernel test robot, Jeff Xu, oe-lkp, lkp, linux-kernel,
Andrew Morton, Kees Cook, Liam R. Howlett, Dave Hansen,
Greg Kroah-Hartman, Guenter Roeck, Jann Horn, Jeff Xu,
Jonathan Corbet, Jorge Lucangeli Obes, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin
In-Reply-To: <CAHk-=whbxLj0thXPzN9aW4CcX1D2_dntNu+x9-8uBakamBggLA@mail.gmail.com>
On Sun, Aug 4, 2024 at 9:33 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sun, 4 Aug 2024 at 01:59, kernel test robot <oliver.sang@intel.com> wrote:
> >
> > kernel test robot noticed a -4.4% regression of stress-ng.pagemove.page_remaps_per_sec on
> > commit 8be7258aad44 ("mseal: add mseal syscall")
>
> Ok, it's basically just the vma walk in can_modify_mm():
>
> > 1.06 +0.1 1.18 perf-profile.self.cycles-pp.mas_next_slot
> > 1.50 +0.5 1.97 perf-profile.self.cycles-pp.mas_find
> > 0.00 +1.4 1.35 perf-profile.self.cycles-pp.can_modify_mm
> > 3.13 +2.0 5.13 perf-profile.self.cycles-pp.mas_walk
>
> and looks like it's two different pathways. We have __do_sys_mremap ->
> mremap_to -> do_munmap -> do_vmi_munmap -> can_modify_mm for the
> destination mapping, but we also have mremap_to() calling
> can_modify_mm() directly for the source mapping.
>
> And then do_vmi_munmap() will do it's *own* vma_find() after having
> done arch_unmap().
>
> And do_munmap() will obviously do its own vma lookup as part of
> calling vma_to_resize().
>
> So it looks like a large portion of this regression is because the
> mseal addition just ends up walking the vma list way too much.
Can we rollback the upfront checks "funny business" and just call
can_modify_vma directly in relevant places? I still don't believe in
the partial mprotect/munmap "security risks" that were stated in the
mseal thread (and these operations can already fail for many other
reasons than mseal) :)
I don't mind taking a look myself, just want to make sure I'm not
stepping on anyone's toes here.
--
Pedro
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Jeff Xu @ 2024-08-05 13:56 UTC (permalink / raw)
To: kernel test robot
Cc: oe-lkp, lkp, linux-kernel, Andrew Morton, Kees Cook,
Liam R. Howlett, Pedro Falcato, Dave Hansen, Greg Kroah-Hartman,
Guenter Roeck, Jann Horn, Jeff Xu, Jonathan Corbet,
Jorge Lucangeli Obes, Linus Torvalds, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin
In-Reply-To: <202408041602.caa0372-oliver.sang@intel.com>
On Sun, Aug 4, 2024 at 1:59 AM kernel test robot <oliver.sang@intel.com> wrote:
>
>
>
> Hello,
>
> kernel test robot noticed a -4.4% regression of stress-ng.pagemove.page_remaps_per_sec on:
>
Looking.
I'm setting up the environment so I can repro. .
>
> commit: 8be7258aad44b5e25977a98db136f677fa6f4370 ("mseal: add mseal syscall")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> testcase: stress-ng
> test machine: 64 threads 2 sockets Intel(R) Xeon(R) Gold 6346 CPU @ 3.10GHz (Ice Lake) with 256G memory
> parameters:
>
> nr_threads: 100%
> testtime: 60s
> test: pagemove
> cpufreq_governor: performance
>
>
> In addition to that, the commit also has significant impact on the following tests:
>
> +------------------+---------------------------------------------------------------------------------------------+
> | testcase: change | stress-ng: stress-ng.pkey.ops_per_sec -3.6% regression |
> | test machine | 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 256G memory |
> | test parameters | cpufreq_governor=performance |
> | | nr_threads=100% |
> | | test=pkey |
> | | testtime=60s |
> +------------------+---------------------------------------------------------------------------------------------+
>
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202408041602.caa0372-oliver.sang@intel.com
>
>
> Details are as below:
> -------------------------------------------------------------------------------------------------->
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20240804/202408041602.caa0372-oliver.sang@intel.com
>
> =========================================================================================
> compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime:
> gcc-13/performance/x86_64-rhel-8.3/100%/debian-12-x86_64-20240206.cgz/lkp-icl-2sp7/pagemove/stress-ng/60s
>
> commit:
> ff388fe5c4 ("mseal: wire up mseal syscall")
> 8be7258aad ("mseal: add mseal syscall")
>
> ff388fe5c481d39c 8be7258aad44b5e25977a98db13
> ---------------- ---------------------------
> %stddev %change %stddev
> \ | \
> 41625945 -4.3% 39842322 proc-vmstat.numa_hit
> 41559175 -4.3% 39774160 proc-vmstat.numa_local
> 77484314 -4.4% 74105555 proc-vmstat.pgalloc_normal
> 77205752 -4.4% 73826672 proc-vmstat.pgfree
> 18361466 -4.2% 17596652 stress-ng.pagemove.ops
> 306014 -4.2% 293262 stress-ng.pagemove.ops_per_sec
> 205312 -4.4% 196176 stress-ng.pagemove.page_remaps_per_sec
> 4961 +1.0% 5013 stress-ng.time.percent_of_cpu_this_job_got
> 2917 +1.2% 2952 stress-ng.time.system_time
> 1.07 -6.6% 1.00 perf-stat.i.MPKI
> 3.354e+10 +3.5% 3.473e+10 perf-stat.i.branch-instructions
> 1.795e+08 -4.2% 1.719e+08 perf-stat.i.cache-misses
> 2.376e+08 -4.1% 2.279e+08 perf-stat.i.cache-references
> 1.13 -3.0% 1.10 perf-stat.i.cpi
> 1077 +4.3% 1124 perf-stat.i.cycles-between-cache-misses
> 1.717e+11 +2.7% 1.762e+11 perf-stat.i.instructions
> 0.88 +3.1% 0.91 perf-stat.i.ipc
> 1.05 -6.8% 0.97 perf-stat.overall.MPKI
> 0.25 ą 2% -0.0 0.24 perf-stat.overall.branch-miss-rate%
> 1.13 -3.0% 1.10 perf-stat.overall.cpi
> 1084 +4.0% 1127 perf-stat.overall.cycles-between-cache-misses
> 0.88 +3.1% 0.91 perf-stat.overall.ipc
> 3.298e+10 +3.5% 3.415e+10 perf-stat.ps.branch-instructions
> 1.764e+08 -4.3% 1.689e+08 perf-stat.ps.cache-misses
> 2.336e+08 -4.1% 2.24e+08 perf-stat.ps.cache-references
> 194.57 -2.4% 189.96 ą 2% perf-stat.ps.cpu-migrations
> 1.688e+11 +2.7% 1.733e+11 perf-stat.ps.instructions
> 1.036e+13 +3.0% 1.068e+13 perf-stat.total.instructions
> 75.12 -1.9 73.22 perf-profile.calltrace.cycles-pp.move_vma.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 36.84 -1.6 35.29 perf-profile.calltrace.cycles-pp.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap.do_syscall_64
> 24.90 -1.2 23.72 perf-profile.calltrace.cycles-pp.copy_vma.move_vma.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 19.89 -0.9 18.98 perf-profile.calltrace.cycles-pp.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 10.56 ą 2% -0.8 9.78 ą 2% perf-profile.calltrace.cycles-pp.rcu_core.handle_softirqs.run_ksoftirqd.smpboot_thread_fn.kthread
> 10.56 ą 2% -0.8 9.79 ą 2% perf-profile.calltrace.cycles-pp.handle_softirqs.run_ksoftirqd.smpboot_thread_fn.kthread.ret_from_fork
> 10.56 ą 2% -0.8 9.79 ą 2% perf-profile.calltrace.cycles-pp.run_ksoftirqd.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
> 10.57 ą 2% -0.8 9.80 ą 2% perf-profile.calltrace.cycles-pp.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
> 10.52 ą 2% -0.8 9.75 ą 2% perf-profile.calltrace.cycles-pp.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd.smpboot_thread_fn
> 10.62 ą 2% -0.8 9.85 ą 2% perf-profile.calltrace.cycles-pp.kthread.ret_from_fork.ret_from_fork_asm
> 10.62 ą 2% -0.8 9.85 ą 2% perf-profile.calltrace.cycles-pp.ret_from_fork.ret_from_fork_asm
> 10.62 ą 2% -0.8 9.85 ą 2% perf-profile.calltrace.cycles-pp.ret_from_fork_asm
> 14.75 -0.7 14.07 perf-profile.calltrace.cycles-pp.vma_merge.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
> 1.50 -0.6 0.94 perf-profile.calltrace.cycles-pp.mas_find.do_vmi_munmap.move_vma.__do_sys_mremap.do_syscall_64
> 5.88 ą 2% -0.4 5.47 ą 2% perf-profile.calltrace.cycles-pp.kmem_cache_free.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd
> 7.80 -0.3 7.47 perf-profile.calltrace.cycles-pp.move_page_tables.move_vma.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 4.55 ą 2% -0.3 4.24 ą 2% perf-profile.calltrace.cycles-pp.__slab_free.kmem_cache_free.rcu_do_batch.rcu_core.handle_softirqs
> 6.76 -0.3 6.45 perf-profile.calltrace.cycles-pp.vm_area_dup.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 6.15 -0.3 5.86 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.vm_area_dup.__split_vma.do_vmi_align_munmap.do_vmi_munmap
> 8.22 -0.3 7.93 perf-profile.calltrace.cycles-pp.unmap_region.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 6.12 -0.3 5.87 perf-profile.calltrace.cycles-pp.vma_complete.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 5.74 -0.2 5.50 perf-profile.calltrace.cycles-pp.move_ptes.move_page_tables.move_vma.__do_sys_mremap.do_syscall_64
> 3.16 ą 2% -0.2 2.94 perf-profile.calltrace.cycles-pp.vm_area_free_rcu_cb.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd
> 5.50 -0.2 5.28 perf-profile.calltrace.cycles-pp.mas_store_prealloc.vma_complete.__split_vma.do_vmi_align_munmap.do_vmi_munmap
> 1.36 -0.2 1.14 perf-profile.calltrace.cycles-pp.mas_find.do_vmi_munmap.do_munmap.mremap_to.__do_sys_mremap
> 5.15 -0.2 4.94 perf-profile.calltrace.cycles-pp.mas_wr_store_entry.mas_store_prealloc.vma_complete.__split_vma.do_vmi_align_munmap
> 5.51 -0.2 5.31 perf-profile.calltrace.cycles-pp.mas_store_prealloc.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 5.16 -0.2 4.97 perf-profile.calltrace.cycles-pp.mas_wr_store_entry.mas_store_prealloc.vma_merge.copy_vma.move_vma
> 2.24 -0.2 2.05 perf-profile.calltrace.cycles-pp.find_vma_prev.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
> 2.60 ą 2% -0.2 2.42 ą 2% perf-profile.calltrace.cycles-pp.kmem_cache_free.vm_area_free_rcu_cb.rcu_do_batch.rcu_core.handle_softirqs
> 4.67 -0.2 4.49 perf-profile.calltrace.cycles-pp.mas_wr_node_store.mas_wr_store_entry.mas_store_prealloc.vma_merge.copy_vma
> 3.41 -0.2 3.23 perf-profile.calltrace.cycles-pp.free_pgtables.unmap_region.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 3.00 -0.2 2.83 ą 2% perf-profile.calltrace.cycles-pp.anon_vma_clone.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 0.96 -0.2 0.80 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.do_vmi_munmap.do_munmap.mremap_to
> 4.04 -0.2 3.88 perf-profile.calltrace.cycles-pp.vm_area_dup.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
> 3.20 ą 2% -0.2 3.04 ą 2% perf-profile.calltrace.cycles-pp.__memcg_slab_post_alloc_hook.kmem_cache_alloc_noprof.vm_area_dup.__split_vma.do_vmi_align_munmap
> 3.53 -0.1 3.38 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.vm_area_dup.copy_vma.move_vma.__do_sys_mremap
> 3.40 -0.1 3.26 perf-profile.calltrace.cycles-pp.flush_tlb_mm_range.move_ptes.move_page_tables.move_vma.__do_sys_mremap
> 2.20 ą 2% -0.1 2.06 ą 2% perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.anon_vma_clone.__split_vma.do_vmi_align_munmap.do_vmi_munmap
> 1.84 ą 3% -0.1 1.71 ą 3% perf-profile.calltrace.cycles-pp.__memcg_slab_post_alloc_hook.kmem_cache_alloc_noprof.anon_vma_clone.__split_vma.do_vmi_align_munmap
> 1.78 ą 2% -0.1 1.65 ą 3% perf-profile.calltrace.cycles-pp.vma_prepare.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 2.69 -0.1 2.56 perf-profile.calltrace.cycles-pp.unlink_anon_vmas.free_pgtables.unmap_region.do_vmi_align_munmap.do_vmi_munmap
> 1.78 ą 2% -0.1 1.66 ą 2% perf-profile.calltrace.cycles-pp.__slab_free.kmem_cache_free.vm_area_free_rcu_cb.rcu_do_batch.rcu_core
> 1.36 ą 2% -0.1 1.23 ą 2% perf-profile.calltrace.cycles-pp.rcu_cblist_dequeue.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd
> 0.95 -0.1 0.83 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.do_vmi_munmap.move_vma.__do_sys_mremap
> 3.29 -0.1 3.17 perf-profile.calltrace.cycles-pp.mas_store_gfp.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 2.08 -0.1 1.96 perf-profile.calltrace.cycles-pp.mas_preallocate.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 1.43 ą 3% -0.1 1.32 ą 3% perf-profile.calltrace.cycles-pp.down_write.vma_prepare.vma_merge.copy_vma.move_vma
> 2.21 -0.1 2.10 perf-profile.calltrace.cycles-pp.mas_preallocate.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 2.47 -0.1 2.36 perf-profile.calltrace.cycles-pp.flush_tlb_func.flush_tlb_mm_range.move_ptes.move_page_tables.move_vma
> 2.21 -0.1 2.12 perf-profile.calltrace.cycles-pp.native_flush_tlb_one_user.flush_tlb_func.flush_tlb_mm_range.move_ptes.move_page_tables
> 1.41 -0.1 1.32 perf-profile.calltrace.cycles-pp.mas_alloc_nodes.mas_preallocate.__split_vma.do_vmi_align_munmap.do_vmi_munmap
> 1.26 -0.1 1.18 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.__split_vma.do_vmi_align_munmap
> 1.82 -0.1 1.75 perf-profile.calltrace.cycles-pp.vma_link.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
> 0.71 -0.1 0.63 perf-profile.calltrace.cycles-pp.mas_prev.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 1.29 -0.1 1.22 perf-profile.calltrace.cycles-pp.mas_wr_store_entry.mas_store_gfp.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 0.61 -0.1 0.54 perf-profile.calltrace.cycles-pp.mas_prev_setup.mas_prev.vma_merge.copy_vma.move_vma
> 1.36 -0.1 1.29 perf-profile.calltrace.cycles-pp.kmem_cache_free.unlink_anon_vmas.free_pgtables.unmap_region.do_vmi_align_munmap
> 1.40 -0.1 1.33 perf-profile.calltrace.cycles-pp.mas_alloc_nodes.mas_preallocate.vma_merge.copy_vma.move_vma
> 0.70 -0.1 0.64 perf-profile.calltrace.cycles-pp.mas_walk.find_vma_prev.copy_vma.move_vma.__do_sys_mremap
> 1.23 -0.1 1.17 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.vma_merge.copy_vma
> 1.66 -0.1 1.60 perf-profile.calltrace.cycles-pp.__get_unmapped_area.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 1.16 -0.1 1.10 perf-profile.calltrace.cycles-pp.anon_vma_clone.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
> 0.96 -0.1 0.90 perf-profile.calltrace.cycles-pp.__memcg_slab_free_hook.kmem_cache_free.unlink_anon_vmas.free_pgtables.unmap_region
> 1.14 -0.1 1.08 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.vm_area_dup.__split_vma.do_vmi_align_munmap
> 0.79 -0.1 0.74 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.__split_vma
> 1.04 -0.1 1.00 perf-profile.calltrace.cycles-pp.vma_to_resize.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 0.58 -0.0 0.53 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64.mremap
> 0.61 -0.0 0.56 perf-profile.calltrace.cycles-pp.__memcg_slab_free_hook.kmem_cache_free.vm_area_free_rcu_cb.rcu_do_batch.rcu_core
> 0.56 -0.0 0.52 perf-profile.calltrace.cycles-pp.mas_find.find_vma_prev.copy_vma.move_vma.__do_sys_mremap
> 0.57 -0.0 0.53 ą 2% perf-profile.calltrace.cycles-pp.__memcg_slab_free_hook.kmem_cache_free.rcu_do_batch.rcu_core.handle_softirqs
> 0.78 -0.0 0.74 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.vma_merge
> 0.88 -0.0 0.84 perf-profile.calltrace.cycles-pp.mtree_load.vma_to_resize.mremap_to.__do_sys_mremap.do_syscall_64
> 0.70 -0.0 0.66 perf-profile.calltrace.cycles-pp.__call_rcu_common.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 0.68 -0.0 0.64 perf-profile.calltrace.cycles-pp.percpu_counter_add_batch.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 0.68 -0.0 0.64 perf-profile.calltrace.cycles-pp.syscall_return_via_sysret.mremap
> 0.97 -0.0 0.93 perf-profile.calltrace.cycles-pp.mas_find.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 1.11 -0.0 1.08 perf-profile.calltrace.cycles-pp.clear_bhb_loop.mremap
> 0.75 -0.0 0.72 perf-profile.calltrace.cycles-pp.allocate_slab.___slab_alloc.kmem_cache_alloc_noprof.vm_area_dup.__split_vma
> 0.74 -0.0 0.71 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.anon_vma_clone.copy_vma.move_vma.__do_sys_mremap
> 0.60 ą 2% -0.0 0.57 perf-profile.calltrace.cycles-pp.security_mmap_addr.__get_unmapped_area.mremap_to.__do_sys_mremap.do_syscall_64
> 0.67 ą 2% -0.0 0.64 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.vm_area_dup.copy_vma.move_vma
> 0.82 -0.0 0.79 perf-profile.calltrace.cycles-pp.mtree_load.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 0.63 -0.0 0.60 perf-profile.calltrace.cycles-pp.mas_prev_slot.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 0.99 -0.0 0.96 perf-profile.calltrace.cycles-pp.mt_find.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 0.62 ą 2% -0.0 0.59 perf-profile.calltrace.cycles-pp.get_old_pud.move_page_tables.move_vma.__do_sys_mremap.do_syscall_64
> 0.87 -0.0 0.84 perf-profile.calltrace.cycles-pp.userfaultfd_unmap_complete.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 0.78 -0.0 0.75 perf-profile.calltrace.cycles-pp.mas_store_prealloc.vma_link.copy_vma.move_vma.__do_sys_mremap
> 0.64 -0.0 0.62 perf-profile.calltrace.cycles-pp.mas_preallocate.vma_link.copy_vma.move_vma.__do_sys_mremap
> 0.90 -0.0 0.87 perf-profile.calltrace.cycles-pp.mtree_load.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 0.54 -0.0 0.52 perf-profile.calltrace.cycles-pp.__pte_offset_map_lock.move_ptes.move_page_tables.move_vma.__do_sys_mremap
> 1.04 +0.0 1.08 perf-profile.calltrace.cycles-pp.zap_pte_range.zap_pmd_range.unmap_page_range.unmap_vmas.unmap_region
> 0.76 +0.1 0.83 perf-profile.calltrace.cycles-pp.__madvise
> 0.63 +0.1 0.70 perf-profile.calltrace.cycles-pp.__x64_sys_madvise.do_syscall_64.entry_SYSCALL_64_after_hwframe.__madvise
> 0.62 +0.1 0.70 perf-profile.calltrace.cycles-pp.do_madvise.__x64_sys_madvise.do_syscall_64.entry_SYSCALL_64_after_hwframe.__madvise
> 0.66 +0.1 0.74 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.__madvise
> 0.66 +0.1 0.74 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.__madvise
> 87.74 +0.7 88.45 perf-profile.calltrace.cycles-pp.mremap
> 0.00 +0.9 0.86 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.can_modify_mm.do_vmi_munmap.do_munmap
> 0.00 +0.9 0.86 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.can_modify_mm.mremap_to.__do_sys_mremap
> 84.88 +0.9 85.77 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.mremap
> 84.73 +0.9 85.62 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 0.00 +0.9 0.92 ą 2% perf-profile.calltrace.cycles-pp.mas_walk.mas_find.can_modify_mm.do_vmi_munmap.move_vma
> 83.84 +0.9 84.78 perf-profile.calltrace.cycles-pp.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 0.00 +1.1 1.06 perf-profile.calltrace.cycles-pp.mas_find.can_modify_mm.mremap_to.__do_sys_mremap.do_syscall_64
> 0.00 +1.2 1.21 perf-profile.calltrace.cycles-pp.mas_find.can_modify_mm.do_vmi_munmap.do_munmap.mremap_to
> 2.07 +1.5 3.55 perf-profile.calltrace.cycles-pp.do_munmap.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 1.58 +1.5 3.07 perf-profile.calltrace.cycles-pp.do_vmi_munmap.do_munmap.mremap_to.__do_sys_mremap.do_syscall_64
> 0.00 +1.5 1.52 perf-profile.calltrace.cycles-pp.mas_find.can_modify_mm.do_vmi_munmap.move_vma.__do_sys_mremap
> 0.00 +1.6 1.57 perf-profile.calltrace.cycles-pp.can_modify_mm.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 0.00 +1.7 1.72 perf-profile.calltrace.cycles-pp.can_modify_mm.do_vmi_munmap.do_munmap.mremap_to.__do_sys_mremap
> 0.00 +2.0 2.01 perf-profile.calltrace.cycles-pp.can_modify_mm.do_vmi_munmap.move_vma.__do_sys_mremap.do_syscall_64
> 5.39 +2.9 8.32 perf-profile.calltrace.cycles-pp.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 75.29 -1.9 73.37 perf-profile.children.cycles-pp.move_vma
> 37.06 -1.6 35.50 perf-profile.children.cycles-pp.do_vmi_align_munmap
> 24.98 -1.2 23.80 perf-profile.children.cycles-pp.copy_vma
> 19.99 -1.0 19.02 perf-profile.children.cycles-pp.handle_softirqs
> 19.97 -1.0 19.00 perf-profile.children.cycles-pp.rcu_core
> 19.95 -1.0 18.98 perf-profile.children.cycles-pp.rcu_do_batch
> 19.98 -0.9 19.06 perf-profile.children.cycles-pp.__split_vma
> 17.55 -0.8 16.76 perf-profile.children.cycles-pp.kmem_cache_free
> 10.56 ą 2% -0.8 9.79 ą 2% perf-profile.children.cycles-pp.run_ksoftirqd
> 10.57 ą 2% -0.8 9.80 ą 2% perf-profile.children.cycles-pp.smpboot_thread_fn
> 15.38 -0.8 14.62 perf-profile.children.cycles-pp.kmem_cache_alloc_noprof
> 10.62 ą 2% -0.8 9.85 ą 2% perf-profile.children.cycles-pp.kthread
> 10.62 ą 2% -0.8 9.86 ą 2% perf-profile.children.cycles-pp.ret_from_fork
> 10.62 ą 2% -0.8 9.86 ą 2% perf-profile.children.cycles-pp.ret_from_fork_asm
> 15.14 -0.7 14.44 perf-profile.children.cycles-pp.vma_merge
> 12.08 -0.5 11.55 perf-profile.children.cycles-pp.__slab_free
> 12.11 -0.5 11.62 perf-profile.children.cycles-pp.mas_wr_store_entry
> 10.86 -0.5 10.39 perf-profile.children.cycles-pp.vm_area_dup
> 11.89 -0.5 11.44 perf-profile.children.cycles-pp.mas_store_prealloc
> 8.49 -0.4 8.06 perf-profile.children.cycles-pp.__memcg_slab_post_alloc_hook
> 9.88 -0.4 9.49 perf-profile.children.cycles-pp.mas_wr_node_store
> 7.91 -0.3 7.58 perf-profile.children.cycles-pp.move_page_tables
> 6.06 -0.3 5.78 perf-profile.children.cycles-pp.vm_area_free_rcu_cb
> 8.28 -0.3 8.00 perf-profile.children.cycles-pp.unmap_region
> 6.69 -0.3 6.42 perf-profile.children.cycles-pp.vma_complete
> 5.06 -0.3 4.80 perf-profile.children.cycles-pp.mas_preallocate
> 5.82 -0.2 5.57 perf-profile.children.cycles-pp.move_ptes
> 4.24 -0.2 4.01 perf-profile.children.cycles-pp.anon_vma_clone
> 3.50 -0.2 3.30 perf-profile.children.cycles-pp.down_write
> 2.44 -0.2 2.25 perf-profile.children.cycles-pp.find_vma_prev
> 3.46 -0.2 3.28 perf-profile.children.cycles-pp.___slab_alloc
> 3.45 -0.2 3.27 perf-profile.children.cycles-pp.free_pgtables
> 2.54 -0.2 2.37 perf-profile.children.cycles-pp.rcu_cblist_dequeue
> 3.35 -0.2 3.18 perf-profile.children.cycles-pp.__memcg_slab_free_hook
> 2.93 -0.2 2.78 perf-profile.children.cycles-pp.mas_alloc_nodes
> 2.28 ą 2% -0.2 2.12 ą 2% perf-profile.children.cycles-pp.vma_prepare
> 3.46 -0.1 3.32 perf-profile.children.cycles-pp.flush_tlb_mm_range
> 3.41 -0.1 3.27 ą 2% perf-profile.children.cycles-pp.mod_objcg_state
> 2.76 -0.1 2.63 perf-profile.children.cycles-pp.unlink_anon_vmas
> 3.41 -0.1 3.28 perf-profile.children.cycles-pp.mas_store_gfp
> 2.21 -0.1 2.09 perf-profile.children.cycles-pp.__cond_resched
> 2.04 -0.1 1.94 perf-profile.children.cycles-pp.allocate_slab
> 2.10 -0.1 2.00 perf-profile.children.cycles-pp.__call_rcu_common
> 2.51 -0.1 2.40 perf-profile.children.cycles-pp.flush_tlb_func
> 1.04 -0.1 0.94 perf-profile.children.cycles-pp.mas_prev
> 2.71 -0.1 2.61 perf-profile.children.cycles-pp.mtree_load
> 2.23 -0.1 2.14 perf-profile.children.cycles-pp.native_flush_tlb_one_user
> 0.22 ą 5% -0.1 0.13 ą 13% perf-profile.children.cycles-pp.vm_stat_account
> 0.95 -0.1 0.87 perf-profile.children.cycles-pp.mas_prev_setup
> 1.65 -0.1 1.57 perf-profile.children.cycles-pp.mas_wr_walk
> 1.84 -0.1 1.76 perf-profile.children.cycles-pp.up_write
> 1.27 -0.1 1.20 perf-profile.children.cycles-pp.mas_prev_slot
> 1.84 -0.1 1.77 perf-profile.children.cycles-pp.vma_link
> 1.39 -0.1 1.32 perf-profile.children.cycles-pp.shuffle_freelist
> 0.96 -0.1 0.90 ą 2% perf-profile.children.cycles-pp.rcu_all_qs
> 0.86 -0.1 0.80 perf-profile.children.cycles-pp._raw_spin_lock_irqsave
> 1.70 -0.1 1.64 perf-profile.children.cycles-pp.__get_unmapped_area
> 0.34 ą 3% -0.1 0.29 ą 5% perf-profile.children.cycles-pp.security_vm_enough_memory_mm
> 0.60 -0.0 0.55 perf-profile.children.cycles-pp.entry_SYSCALL_64
> 0.92 -0.0 0.87 perf-profile.children.cycles-pp.percpu_counter_add_batch
> 1.07 -0.0 1.02 perf-profile.children.cycles-pp.vma_to_resize
> 1.59 -0.0 1.54 perf-profile.children.cycles-pp.mas_update_gap
> 0.44 ą 2% -0.0 0.40 ą 2% perf-profile.children.cycles-pp.native_queued_spin_lock_slowpath
> 0.70 -0.0 0.66 perf-profile.children.cycles-pp.syscall_return_via_sysret
> 1.13 -0.0 1.09 perf-profile.children.cycles-pp.mt_find
> 0.20 ą 6% -0.0 0.17 ą 9% perf-profile.children.cycles-pp.cap_vm_enough_memory
> 0.99 -0.0 0.95 perf-profile.children.cycles-pp.mas_pop_node
> 0.63 ą 2% -0.0 0.59 perf-profile.children.cycles-pp.security_mmap_addr
> 0.62 -0.0 0.59 perf-profile.children.cycles-pp.__put_partials
> 1.17 -0.0 1.14 perf-profile.children.cycles-pp.clear_bhb_loop
> 0.46 -0.0 0.43 ą 2% perf-profile.children.cycles-pp.__alloc_pages_noprof
> 0.44 -0.0 0.41 ą 2% perf-profile.children.cycles-pp.get_page_from_freelist
> 0.90 -0.0 0.87 perf-profile.children.cycles-pp.userfaultfd_unmap_complete
> 0.64 ą 2% -0.0 0.62 perf-profile.children.cycles-pp.get_old_pud
> 1.07 -0.0 1.05 perf-profile.children.cycles-pp.mas_leaf_max_gap
> 0.22 ą 3% -0.0 0.20 ą 2% perf-profile.children.cycles-pp.__rmqueue_pcplist
> 0.55 -0.0 0.53 perf-profile.children.cycles-pp.refill_obj_stock
> 0.25 -0.0 0.23 ą 3% perf-profile.children.cycles-pp.rmqueue
> 0.48 -0.0 0.45 perf-profile.children.cycles-pp.mremap_userfaultfd_prep
> 0.33 -0.0 0.30 perf-profile.children.cycles-pp.free_unref_page
> 0.46 -0.0 0.44 perf-profile.children.cycles-pp.setup_object
> 0.21 ą 3% -0.0 0.19 ą 2% perf-profile.children.cycles-pp.rmqueue_bulk
> 0.31 ą 3% -0.0 0.29 perf-profile.children.cycles-pp.__vm_enough_memory
> 0.40 -0.0 0.38 perf-profile.children.cycles-pp.entry_SYSRETQ_unsafe_stack
> 0.36 -0.0 0.35 perf-profile.children.cycles-pp.madvise_vma_behavior
> 0.54 -0.0 0.53 ą 2% perf-profile.children.cycles-pp.mas_wr_end_piv
> 0.46 -0.0 0.44 ą 2% perf-profile.children.cycles-pp.rcu_segcblist_enqueue
> 0.34 -0.0 0.32 ą 2% perf-profile.children.cycles-pp.mas_destroy
> 0.28 -0.0 0.26 ą 3% perf-profile.children.cycles-pp.mas_wr_store_setup
> 0.30 -0.0 0.28 perf-profile.children.cycles-pp.pte_offset_map_nolock
> 0.19 -0.0 0.18 ą 2% perf-profile.children.cycles-pp.__thp_vma_allowable_orders
> 0.08 ą 4% -0.0 0.07 perf-profile.children.cycles-pp.ksm_madvise
> 0.17 -0.0 0.16 perf-profile.children.cycles-pp.get_any_partial
> 0.08 -0.0 0.07 perf-profile.children.cycles-pp.syscall_exit_to_user_mode_prepare
> 0.45 +0.0 0.47 perf-profile.children.cycles-pp._raw_spin_lock
> 1.10 +0.0 1.14 perf-profile.children.cycles-pp.zap_pte_range
> 0.78 +0.1 0.85 perf-profile.children.cycles-pp.__madvise
> 0.63 +0.1 0.70 perf-profile.children.cycles-pp.__x64_sys_madvise
> 0.62 +0.1 0.70 perf-profile.children.cycles-pp.do_madvise
> 0.00 +0.1 0.09 ą 4% perf-profile.children.cycles-pp.can_modify_mm_madv
> 1.32 +0.1 1.46 perf-profile.children.cycles-pp.mas_next_slot
> 88.13 +0.7 88.83 perf-profile.children.cycles-pp.mremap
> 83.94 +0.9 84.88 perf-profile.children.cycles-pp.__do_sys_mremap
> 86.06 +0.9 87.00 perf-profile.children.cycles-pp.entry_SYSCALL_64_after_hwframe
> 85.56 +1.0 86.54 perf-profile.children.cycles-pp.do_syscall_64
> 40.49 +1.4 41.90 perf-profile.children.cycles-pp.do_vmi_munmap
> 2.10 +1.5 3.57 perf-profile.children.cycles-pp.do_munmap
> 3.62 +2.3 5.90 perf-profile.children.cycles-pp.mas_walk
> 5.44 +2.9 8.38 perf-profile.children.cycles-pp.mremap_to
> 5.30 +3.1 8.39 perf-profile.children.cycles-pp.mas_find
> 0.00 +5.4 5.40 perf-profile.children.cycles-pp.can_modify_mm
> 11.46 -0.5 10.96 perf-profile.self.cycles-pp.__slab_free
> 4.30 -0.2 4.08 perf-profile.self.cycles-pp.__memcg_slab_post_alloc_hook
> 2.51 -0.2 2.34 perf-profile.self.cycles-pp.rcu_cblist_dequeue
> 2.41 ą 2% -0.2 2.25 perf-profile.self.cycles-pp.down_write
> 2.21 -0.1 2.11 perf-profile.self.cycles-pp.native_flush_tlb_one_user
> 2.37 -0.1 2.28 perf-profile.self.cycles-pp.mtree_load
> 1.60 -0.1 1.51 perf-profile.self.cycles-pp.__memcg_slab_free_hook
> 0.18 ą 3% -0.1 0.10 ą 15% perf-profile.self.cycles-pp.vm_stat_account
> 1.25 -0.1 1.18 perf-profile.self.cycles-pp.move_vma
> 1.76 -0.1 1.69 perf-profile.self.cycles-pp.mod_objcg_state
> 1.42 -0.1 1.35 ą 2% perf-profile.self.cycles-pp.__call_rcu_common
> 1.41 -0.1 1.34 perf-profile.self.cycles-pp.mas_wr_walk
> 1.52 -0.1 1.46 perf-profile.self.cycles-pp.up_write
> 1.02 -0.1 0.95 perf-profile.self.cycles-pp.mas_prev_slot
> 0.96 -0.1 0.90 ą 2% perf-profile.self.cycles-pp.vm_area_free_rcu_cb
> 1.50 -0.1 1.45 perf-profile.self.cycles-pp.kmem_cache_free
> 0.69 ą 3% -0.1 0.64 ą 2% perf-profile.self.cycles-pp.rcu_all_qs
> 1.14 ą 2% -0.1 1.09 perf-profile.self.cycles-pp.shuffle_freelist
> 1.10 -0.1 1.05 perf-profile.self.cycles-pp.__cond_resched
> 1.40 -0.0 1.35 perf-profile.self.cycles-pp.do_vmi_align_munmap
> 0.99 -0.0 0.94 perf-profile.self.cycles-pp.mas_preallocate
> 0.88 -0.0 0.83 perf-profile.self.cycles-pp.___slab_alloc
> 0.55 -0.0 0.50 perf-profile.self.cycles-pp.mremap_to
> 0.98 -0.0 0.93 perf-profile.self.cycles-pp.move_ptes
> 0.78 -0.0 0.74 perf-profile.self.cycles-pp.percpu_counter_add_batch
> 0.21 ą 2% -0.0 0.18 ą 2% perf-profile.self.cycles-pp.entry_SYSCALL_64
> 0.44 ą 2% -0.0 0.40 ą 2% perf-profile.self.cycles-pp.native_queued_spin_lock_slowpath
> 0.92 -0.0 0.89 perf-profile.self.cycles-pp.mas_store_gfp
> 0.86 -0.0 0.82 perf-profile.self.cycles-pp.mas_pop_node
> 0.50 -0.0 0.46 perf-profile.self.cycles-pp.entry_SYSCALL_64_after_hwframe
> 1.15 -0.0 1.12 perf-profile.self.cycles-pp.clear_bhb_loop
> 1.14 -0.0 1.11 perf-profile.self.cycles-pp.vma_merge
> 0.66 -0.0 0.63 perf-profile.self.cycles-pp.__split_vma
> 0.16 ą 6% -0.0 0.13 ą 7% perf-profile.self.cycles-pp.cap_vm_enough_memory
> 0.82 -0.0 0.79 perf-profile.self.cycles-pp.mas_wr_store_entry
> 0.54 ą 2% -0.0 0.52 perf-profile.self.cycles-pp.get_old_pud
> 0.43 -0.0 0.40 perf-profile.self.cycles-pp.do_munmap
> 0.51 ą 2% -0.0 0.48 ą 2% perf-profile.self.cycles-pp.security_mmap_addr
> 0.50 -0.0 0.48 perf-profile.self.cycles-pp.refill_obj_stock
> 0.24 -0.0 0.22 perf-profile.self.cycles-pp.mas_prev
> 0.71 -0.0 0.69 perf-profile.self.cycles-pp.unmap_page_range
> 0.48 -0.0 0.45 perf-profile.self.cycles-pp.find_vma_prev
> 0.42 -0.0 0.40 perf-profile.self.cycles-pp._raw_spin_lock_irqsave
> 0.66 -0.0 0.64 perf-profile.self.cycles-pp.mas_store_prealloc
> 0.31 -0.0 0.29 perf-profile.self.cycles-pp.mas_prev_setup
> 0.43 -0.0 0.41 perf-profile.self.cycles-pp.mas_wr_end_piv
> 0.78 -0.0 0.76 perf-profile.self.cycles-pp.userfaultfd_unmap_complete
> 0.28 -0.0 0.26 ą 2% perf-profile.self.cycles-pp.mas_put_in_tree
> 0.42 -0.0 0.40 perf-profile.self.cycles-pp.mremap_userfaultfd_prep
> 0.28 -0.0 0.26 perf-profile.self.cycles-pp.free_pgtables
> 0.39 -0.0 0.37 perf-profile.self.cycles-pp.entry_SYSRETQ_unsafe_stack
> 0.30 ą 2% -0.0 0.28 perf-profile.self.cycles-pp.zap_pmd_range
> 0.32 -0.0 0.31 perf-profile.self.cycles-pp.unmap_vmas
> 0.21 -0.0 0.20 perf-profile.self.cycles-pp.__get_unmapped_area
> 0.18 ą 2% -0.0 0.17 ą 2% perf-profile.self.cycles-pp.lru_add_drain_cpu
> 0.06 -0.0 0.05 perf-profile.self.cycles-pp.ksm_madvise
> 0.45 +0.0 0.46 perf-profile.self.cycles-pp.do_vmi_munmap
> 0.37 +0.0 0.39 perf-profile.self.cycles-pp._raw_spin_lock
> 1.06 +0.1 1.18 perf-profile.self.cycles-pp.mas_next_slot
> 1.50 +0.5 1.97 perf-profile.self.cycles-pp.mas_find
> 0.00 +1.4 1.35 perf-profile.self.cycles-pp.can_modify_mm
> 3.13 +2.0 5.13 perf-profile.self.cycles-pp.mas_walk
>
>
> ***************************************************************************************************
> lkp-spr-r02: 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 256G memory
> =========================================================================================
> compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime:
> gcc-13/performance/x86_64-rhel-8.3/100%/debian-12-x86_64-20240206.cgz/lkp-spr-r02/pkey/stress-ng/60s
>
> commit:
> ff388fe5c4 ("mseal: wire up mseal syscall")
> 8be7258aad ("mseal: add mseal syscall")
>
> ff388fe5c481d39c 8be7258aad44b5e25977a98db13
> ---------------- ---------------------------
> %stddev %change %stddev
> \ | \
> 10539 -2.5% 10273 vmstat.system.cs
> 0.28 ą 5% -20.1% 0.22 ą 7% sched_debug.cfs_rq:/.h_nr_running.stddev
> 1419 ą 7% -15.3% 1202 ą 6% sched_debug.cfs_rq:/.util_avg.max
> 0.28 ą 6% -18.4% 0.23 ą 8% sched_debug.cpu.nr_running.stddev
> 8.736e+08 -3.6% 8.423e+08 stress-ng.pkey.ops
> 14560560 -3.6% 14038795 stress-ng.pkey.ops_per_sec
> 770.39 ą 4% -5.0% 732.04 stress-ng.time.user_time
> 244657 ą 3% +5.8% 258782 ą 3% proc-vmstat.nr_slab_unreclaimable
> 73133541 -2.1% 71588873 proc-vmstat.numa_hit
> 72873579 -2.1% 71357274 proc-vmstat.numa_local
> 1.842e+08 -2.5% 1.796e+08 proc-vmstat.pgalloc_normal
> 1.767e+08 -2.8% 1.717e+08 proc-vmstat.pgfree
> 1345346 ą 40% -73.1% 362064 ą124% numa-vmstat.node0.nr_inactive_anon
> 1345340 ą 40% -73.1% 362062 ą124% numa-vmstat.node0.nr_zone_inactive_anon
> 2420830 ą 14% +35.1% 3270248 ą 16% numa-vmstat.node1.nr_file_pages
> 2067871 ą 13% +51.5% 3132982 ą 17% numa-vmstat.node1.nr_inactive_anon
> 191406 ą 17% +33.6% 255808 ą 14% numa-vmstat.node1.nr_mapped
> 2452 ą 61% +104.4% 5012 ą 35% numa-vmstat.node1.nr_page_table_pages
> 2067853 ą 13% +51.5% 3132966 ą 17% numa-vmstat.node1.nr_zone_inactive_anon
> 5379238 ą 40% -73.0% 1453605 ą123% numa-meminfo.node0.Inactive
> 5379166 ą 40% -73.0% 1453462 ą123% numa-meminfo.node0.Inactive(anon)
> 8741077 ą 22% -36.7% 5531290 ą 28% numa-meminfo.node0.MemUsed
> 9651902 ą 13% +35.8% 13105318 ą 16% numa-meminfo.node1.FilePages
> 8239855 ą 13% +52.4% 12556929 ą 17% numa-meminfo.node1.Inactive
> 8239712 ą 13% +52.4% 12556853 ą 17% numa-meminfo.node1.Inactive(anon)
> 761944 ą 18% +34.6% 1025906 ą 14% numa-meminfo.node1.Mapped
> 11679628 ą 11% +31.2% 15322841 ą 14% numa-meminfo.node1.MemUsed
> 9874 ą 62% +104.6% 20200 ą 36% numa-meminfo.node1.PageTables
> 0.74 -4.2% 0.71 perf-stat.i.MPKI
> 1.245e+11 +2.3% 1.274e+11 perf-stat.i.branch-instructions
> 0.37 -0.0 0.35 perf-stat.i.branch-miss-rate%
> 4.359e+08 -2.1% 4.265e+08 perf-stat.i.branch-misses
> 4.672e+08 -2.6% 4.548e+08 perf-stat.i.cache-misses
> 7.276e+08 -2.7% 7.082e+08 perf-stat.i.cache-references
> 1.00 -1.6% 0.98 perf-stat.i.cpi
> 1364 +2.9% 1404 perf-stat.i.cycles-between-cache-misses
> 6.392e+11 +1.7% 6.499e+11 perf-stat.i.instructions
> 1.00 +1.6% 1.02 perf-stat.i.ipc
> 0.74 -4.3% 0.71 perf-stat.overall.MPKI
> 0.35 -0.0 0.33 perf-stat.overall.branch-miss-rate%
> 1.00 -1.6% 0.99 perf-stat.overall.cpi
> 1356 +2.9% 1395 perf-stat.overall.cycles-between-cache-misses
> 1.00 +1.6% 1.01 perf-stat.overall.ipc
> 1.209e+11 +1.9% 1.232e+11 perf-stat.ps.branch-instructions
> 4.188e+08 -2.6% 4.077e+08 perf-stat.ps.branch-misses
> 4.585e+08 -3.1% 4.441e+08 perf-stat.ps.cache-misses
> 7.124e+08 -3.1% 6.901e+08 perf-stat.ps.cache-references
> 10321 -2.6% 10053 perf-stat.ps.context-switches
>
>
>
>
>
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
>
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Jeff Xu @ 2024-08-05 16:58 UTC (permalink / raw)
To: kernel test robot
Cc: oe-lkp, lkp, linux-kernel, Andrew Morton, Kees Cook,
Liam R. Howlett, Pedro Falcato, Dave Hansen, Greg Kroah-Hartman,
Guenter Roeck, Jann Horn, Jeff Xu, Jonathan Corbet,
Jorge Lucangeli Obes, Linus Torvalds, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin
In-Reply-To: <202408041602.caa0372-oliver.sang@intel.com>
On Sun, Aug 4, 2024 at 1:59 AM kernel test robot <oliver.sang@intel.com> wrote:
>
>
>
> Hello,
>
> kernel test robot noticed a -4.4% regression of stress-ng.pagemove.page_remaps_per_sec on:
>
>
> commit: 8be7258aad44b5e25977a98db136f677fa6f4370 ("mseal: add mseal syscall")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> testcase: stress-ng
> test machine: 64 threads 2 sockets Intel(R) Xeon(R) Gold 6346 CPU @ 3.10GHz (Ice Lake) with 256G memory
> parameters:
>
> nr_threads: 100%
> testtime: 60s
> test: pagemove
> cpufreq_governor: performance
>
>
> In addition to that, the commit also has significant impact on the following tests:
>
> +------------------+---------------------------------------------------------------------------------------------+
> | testcase: change | stress-ng: stress-ng.pkey.ops_per_sec -3.6% regression |
> | test machine | 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 256G memory |
> | test parameters | cpufreq_governor=performance |
> | | nr_threads=100% |
> | | test=pkey |
> | | testtime=60s |
> +------------------+---------------------------------------------------------------------------------------------+
>
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202408041602.caa0372-oliver.sang@intel.com
>
>
> Details are as below:
> -------------------------------------------------------------------------------------------------->
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20240804/202408041602.caa0372-oliver.sang@intel.com
>
There is an error when I try to reproduce the test:
bin/lkp install job.yaml
--------------------------------------------------------
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libdw1 : Depends: libelf1 (= 0.190-1+b1)
libdw1t64 : Breaks: libdw1 (< 0.191-2)
E: Unable to correct problems, you have held broken packages.
Cannot install some packages of perf-c2c depends
-----------------------------------------------------------------------------------------
And where is stress-ng.pagemove.page_remaps_per_sec test implemented,
is that part of lkp-tests ?
Thanks
-Jeff
> =========================================================================================
> compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime:
> gcc-13/performance/x86_64-rhel-8.3/100%/debian-12-x86_64-20240206.cgz/lkp-icl-2sp7/pagemove/stress-ng/60s
>
> commit:
> ff388fe5c4 ("mseal: wire up mseal syscall")
> 8be7258aad ("mseal: add mseal syscall")
>
> ff388fe5c481d39c 8be7258aad44b5e25977a98db13
> ---------------- ---------------------------
> %stddev %change %stddev
> \ | \
> 41625945 -4.3% 39842322 proc-vmstat.numa_hit
> 41559175 -4.3% 39774160 proc-vmstat.numa_local
> 77484314 -4.4% 74105555 proc-vmstat.pgalloc_normal
> 77205752 -4.4% 73826672 proc-vmstat.pgfree
> 18361466 -4.2% 17596652 stress-ng.pagemove.ops
> 306014 -4.2% 293262 stress-ng.pagemove.ops_per_sec
> 205312 -4.4% 196176 stress-ng.pagemove.page_remaps_per_sec
> 4961 +1.0% 5013 stress-ng.time.percent_of_cpu_this_job_got
> 2917 +1.2% 2952 stress-ng.time.system_time
> 1.07 -6.6% 1.00 perf-stat.i.MPKI
> 3.354e+10 +3.5% 3.473e+10 perf-stat.i.branch-instructions
> 1.795e+08 -4.2% 1.719e+08 perf-stat.i.cache-misses
> 2.376e+08 -4.1% 2.279e+08 perf-stat.i.cache-references
> 1.13 -3.0% 1.10 perf-stat.i.cpi
> 1077 +4.3% 1124 perf-stat.i.cycles-between-cache-misses
> 1.717e+11 +2.7% 1.762e+11 perf-stat.i.instructions
> 0.88 +3.1% 0.91 perf-stat.i.ipc
> 1.05 -6.8% 0.97 perf-stat.overall.MPKI
> 0.25 ą 2% -0.0 0.24 perf-stat.overall.branch-miss-rate%
> 1.13 -3.0% 1.10 perf-stat.overall.cpi
> 1084 +4.0% 1127 perf-stat.overall.cycles-between-cache-misses
> 0.88 +3.1% 0.91 perf-stat.overall.ipc
> 3.298e+10 +3.5% 3.415e+10 perf-stat.ps.branch-instructions
> 1.764e+08 -4.3% 1.689e+08 perf-stat.ps.cache-misses
> 2.336e+08 -4.1% 2.24e+08 perf-stat.ps.cache-references
> 194.57 -2.4% 189.96 ą 2% perf-stat.ps.cpu-migrations
> 1.688e+11 +2.7% 1.733e+11 perf-stat.ps.instructions
> 1.036e+13 +3.0% 1.068e+13 perf-stat.total.instructions
> 75.12 -1.9 73.22 perf-profile.calltrace.cycles-pp.move_vma.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 36.84 -1.6 35.29 perf-profile.calltrace.cycles-pp.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap.do_syscall_64
> 24.90 -1.2 23.72 perf-profile.calltrace.cycles-pp.copy_vma.move_vma.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 19.89 -0.9 18.98 perf-profile.calltrace.cycles-pp.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 10.56 ą 2% -0.8 9.78 ą 2% perf-profile.calltrace.cycles-pp.rcu_core.handle_softirqs.run_ksoftirqd.smpboot_thread_fn.kthread
> 10.56 ą 2% -0.8 9.79 ą 2% perf-profile.calltrace.cycles-pp.handle_softirqs.run_ksoftirqd.smpboot_thread_fn.kthread.ret_from_fork
> 10.56 ą 2% -0.8 9.79 ą 2% perf-profile.calltrace.cycles-pp.run_ksoftirqd.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
> 10.57 ą 2% -0.8 9.80 ą 2% perf-profile.calltrace.cycles-pp.smpboot_thread_fn.kthread.ret_from_fork.ret_from_fork_asm
> 10.52 ą 2% -0.8 9.75 ą 2% perf-profile.calltrace.cycles-pp.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd.smpboot_thread_fn
> 10.62 ą 2% -0.8 9.85 ą 2% perf-profile.calltrace.cycles-pp.kthread.ret_from_fork.ret_from_fork_asm
> 10.62 ą 2% -0.8 9.85 ą 2% perf-profile.calltrace.cycles-pp.ret_from_fork.ret_from_fork_asm
> 10.62 ą 2% -0.8 9.85 ą 2% perf-profile.calltrace.cycles-pp.ret_from_fork_asm
> 14.75 -0.7 14.07 perf-profile.calltrace.cycles-pp.vma_merge.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
> 1.50 -0.6 0.94 perf-profile.calltrace.cycles-pp.mas_find.do_vmi_munmap.move_vma.__do_sys_mremap.do_syscall_64
> 5.88 ą 2% -0.4 5.47 ą 2% perf-profile.calltrace.cycles-pp.kmem_cache_free.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd
> 7.80 -0.3 7.47 perf-profile.calltrace.cycles-pp.move_page_tables.move_vma.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 4.55 ą 2% -0.3 4.24 ą 2% perf-profile.calltrace.cycles-pp.__slab_free.kmem_cache_free.rcu_do_batch.rcu_core.handle_softirqs
> 6.76 -0.3 6.45 perf-profile.calltrace.cycles-pp.vm_area_dup.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 6.15 -0.3 5.86 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.vm_area_dup.__split_vma.do_vmi_align_munmap.do_vmi_munmap
> 8.22 -0.3 7.93 perf-profile.calltrace.cycles-pp.unmap_region.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 6.12 -0.3 5.87 perf-profile.calltrace.cycles-pp.vma_complete.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 5.74 -0.2 5.50 perf-profile.calltrace.cycles-pp.move_ptes.move_page_tables.move_vma.__do_sys_mremap.do_syscall_64
> 3.16 ą 2% -0.2 2.94 perf-profile.calltrace.cycles-pp.vm_area_free_rcu_cb.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd
> 5.50 -0.2 5.28 perf-profile.calltrace.cycles-pp.mas_store_prealloc.vma_complete.__split_vma.do_vmi_align_munmap.do_vmi_munmap
> 1.36 -0.2 1.14 perf-profile.calltrace.cycles-pp.mas_find.do_vmi_munmap.do_munmap.mremap_to.__do_sys_mremap
> 5.15 -0.2 4.94 perf-profile.calltrace.cycles-pp.mas_wr_store_entry.mas_store_prealloc.vma_complete.__split_vma.do_vmi_align_munmap
> 5.51 -0.2 5.31 perf-profile.calltrace.cycles-pp.mas_store_prealloc.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 5.16 -0.2 4.97 perf-profile.calltrace.cycles-pp.mas_wr_store_entry.mas_store_prealloc.vma_merge.copy_vma.move_vma
> 2.24 -0.2 2.05 perf-profile.calltrace.cycles-pp.find_vma_prev.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
> 2.60 ą 2% -0.2 2.42 ą 2% perf-profile.calltrace.cycles-pp.kmem_cache_free.vm_area_free_rcu_cb.rcu_do_batch.rcu_core.handle_softirqs
> 4.67 -0.2 4.49 perf-profile.calltrace.cycles-pp.mas_wr_node_store.mas_wr_store_entry.mas_store_prealloc.vma_merge.copy_vma
> 3.41 -0.2 3.23 perf-profile.calltrace.cycles-pp.free_pgtables.unmap_region.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 3.00 -0.2 2.83 ą 2% perf-profile.calltrace.cycles-pp.anon_vma_clone.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 0.96 -0.2 0.80 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.do_vmi_munmap.do_munmap.mremap_to
> 4.04 -0.2 3.88 perf-profile.calltrace.cycles-pp.vm_area_dup.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
> 3.20 ą 2% -0.2 3.04 ą 2% perf-profile.calltrace.cycles-pp.__memcg_slab_post_alloc_hook.kmem_cache_alloc_noprof.vm_area_dup.__split_vma.do_vmi_align_munmap
> 3.53 -0.1 3.38 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.vm_area_dup.copy_vma.move_vma.__do_sys_mremap
> 3.40 -0.1 3.26 perf-profile.calltrace.cycles-pp.flush_tlb_mm_range.move_ptes.move_page_tables.move_vma.__do_sys_mremap
> 2.20 ą 2% -0.1 2.06 ą 2% perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.anon_vma_clone.__split_vma.do_vmi_align_munmap.do_vmi_munmap
> 1.84 ą 3% -0.1 1.71 ą 3% perf-profile.calltrace.cycles-pp.__memcg_slab_post_alloc_hook.kmem_cache_alloc_noprof.anon_vma_clone.__split_vma.do_vmi_align_munmap
> 1.78 ą 2% -0.1 1.65 ą 3% perf-profile.calltrace.cycles-pp.vma_prepare.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 2.69 -0.1 2.56 perf-profile.calltrace.cycles-pp.unlink_anon_vmas.free_pgtables.unmap_region.do_vmi_align_munmap.do_vmi_munmap
> 1.78 ą 2% -0.1 1.66 ą 2% perf-profile.calltrace.cycles-pp.__slab_free.kmem_cache_free.vm_area_free_rcu_cb.rcu_do_batch.rcu_core
> 1.36 ą 2% -0.1 1.23 ą 2% perf-profile.calltrace.cycles-pp.rcu_cblist_dequeue.rcu_do_batch.rcu_core.handle_softirqs.run_ksoftirqd
> 0.95 -0.1 0.83 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.do_vmi_munmap.move_vma.__do_sys_mremap
> 3.29 -0.1 3.17 perf-profile.calltrace.cycles-pp.mas_store_gfp.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 2.08 -0.1 1.96 perf-profile.calltrace.cycles-pp.mas_preallocate.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 1.43 ą 3% -0.1 1.32 ą 3% perf-profile.calltrace.cycles-pp.down_write.vma_prepare.vma_merge.copy_vma.move_vma
> 2.21 -0.1 2.10 perf-profile.calltrace.cycles-pp.mas_preallocate.__split_vma.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 2.47 -0.1 2.36 perf-profile.calltrace.cycles-pp.flush_tlb_func.flush_tlb_mm_range.move_ptes.move_page_tables.move_vma
> 2.21 -0.1 2.12 perf-profile.calltrace.cycles-pp.native_flush_tlb_one_user.flush_tlb_func.flush_tlb_mm_range.move_ptes.move_page_tables
> 1.41 -0.1 1.32 perf-profile.calltrace.cycles-pp.mas_alloc_nodes.mas_preallocate.__split_vma.do_vmi_align_munmap.do_vmi_munmap
> 1.26 -0.1 1.18 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.__split_vma.do_vmi_align_munmap
> 1.82 -0.1 1.75 perf-profile.calltrace.cycles-pp.vma_link.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
> 0.71 -0.1 0.63 perf-profile.calltrace.cycles-pp.mas_prev.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 1.29 -0.1 1.22 perf-profile.calltrace.cycles-pp.mas_wr_store_entry.mas_store_gfp.do_vmi_align_munmap.do_vmi_munmap.move_vma
> 0.61 -0.1 0.54 perf-profile.calltrace.cycles-pp.mas_prev_setup.mas_prev.vma_merge.copy_vma.move_vma
> 1.36 -0.1 1.29 perf-profile.calltrace.cycles-pp.kmem_cache_free.unlink_anon_vmas.free_pgtables.unmap_region.do_vmi_align_munmap
> 1.40 -0.1 1.33 perf-profile.calltrace.cycles-pp.mas_alloc_nodes.mas_preallocate.vma_merge.copy_vma.move_vma
> 0.70 -0.1 0.64 perf-profile.calltrace.cycles-pp.mas_walk.find_vma_prev.copy_vma.move_vma.__do_sys_mremap
> 1.23 -0.1 1.17 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.vma_merge.copy_vma
> 1.66 -0.1 1.60 perf-profile.calltrace.cycles-pp.__get_unmapped_area.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 1.16 -0.1 1.10 perf-profile.calltrace.cycles-pp.anon_vma_clone.copy_vma.move_vma.__do_sys_mremap.do_syscall_64
> 0.96 -0.1 0.90 perf-profile.calltrace.cycles-pp.__memcg_slab_free_hook.kmem_cache_free.unlink_anon_vmas.free_pgtables.unmap_region
> 1.14 -0.1 1.08 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.vm_area_dup.__split_vma.do_vmi_align_munmap
> 0.79 -0.1 0.74 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.__split_vma
> 1.04 -0.1 1.00 perf-profile.calltrace.cycles-pp.vma_to_resize.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 0.58 -0.0 0.53 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64.mremap
> 0.61 -0.0 0.56 perf-profile.calltrace.cycles-pp.__memcg_slab_free_hook.kmem_cache_free.vm_area_free_rcu_cb.rcu_do_batch.rcu_core
> 0.56 -0.0 0.52 perf-profile.calltrace.cycles-pp.mas_find.find_vma_prev.copy_vma.move_vma.__do_sys_mremap
> 0.57 -0.0 0.53 ą 2% perf-profile.calltrace.cycles-pp.__memcg_slab_free_hook.kmem_cache_free.rcu_do_batch.rcu_core.handle_softirqs
> 0.78 -0.0 0.74 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.mas_alloc_nodes.mas_preallocate.vma_merge
> 0.88 -0.0 0.84 perf-profile.calltrace.cycles-pp.mtree_load.vma_to_resize.mremap_to.__do_sys_mremap.do_syscall_64
> 0.70 -0.0 0.66 perf-profile.calltrace.cycles-pp.__call_rcu_common.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 0.68 -0.0 0.64 perf-profile.calltrace.cycles-pp.percpu_counter_add_batch.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 0.68 -0.0 0.64 perf-profile.calltrace.cycles-pp.syscall_return_via_sysret.mremap
> 0.97 -0.0 0.93 perf-profile.calltrace.cycles-pp.mas_find.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 1.11 -0.0 1.08 perf-profile.calltrace.cycles-pp.clear_bhb_loop.mremap
> 0.75 -0.0 0.72 perf-profile.calltrace.cycles-pp.allocate_slab.___slab_alloc.kmem_cache_alloc_noprof.vm_area_dup.__split_vma
> 0.74 -0.0 0.71 perf-profile.calltrace.cycles-pp.kmem_cache_alloc_noprof.anon_vma_clone.copy_vma.move_vma.__do_sys_mremap
> 0.60 ą 2% -0.0 0.57 perf-profile.calltrace.cycles-pp.security_mmap_addr.__get_unmapped_area.mremap_to.__do_sys_mremap.do_syscall_64
> 0.67 ą 2% -0.0 0.64 perf-profile.calltrace.cycles-pp.___slab_alloc.kmem_cache_alloc_noprof.vm_area_dup.copy_vma.move_vma
> 0.82 -0.0 0.79 perf-profile.calltrace.cycles-pp.mtree_load.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 0.63 -0.0 0.60 perf-profile.calltrace.cycles-pp.mas_prev_slot.do_vmi_align_munmap.do_vmi_munmap.move_vma.__do_sys_mremap
> 0.99 -0.0 0.96 perf-profile.calltrace.cycles-pp.mt_find.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 0.62 ą 2% -0.0 0.59 perf-profile.calltrace.cycles-pp.get_old_pud.move_page_tables.move_vma.__do_sys_mremap.do_syscall_64
> 0.87 -0.0 0.84 perf-profile.calltrace.cycles-pp.userfaultfd_unmap_complete.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 0.78 -0.0 0.75 perf-profile.calltrace.cycles-pp.mas_store_prealloc.vma_link.copy_vma.move_vma.__do_sys_mremap
> 0.64 -0.0 0.62 perf-profile.calltrace.cycles-pp.mas_preallocate.vma_link.copy_vma.move_vma.__do_sys_mremap
> 0.90 -0.0 0.87 perf-profile.calltrace.cycles-pp.mtree_load.vma_merge.copy_vma.move_vma.__do_sys_mremap
> 0.54 -0.0 0.52 perf-profile.calltrace.cycles-pp.__pte_offset_map_lock.move_ptes.move_page_tables.move_vma.__do_sys_mremap
> 1.04 +0.0 1.08 perf-profile.calltrace.cycles-pp.zap_pte_range.zap_pmd_range.unmap_page_range.unmap_vmas.unmap_region
> 0.76 +0.1 0.83 perf-profile.calltrace.cycles-pp.__madvise
> 0.63 +0.1 0.70 perf-profile.calltrace.cycles-pp.__x64_sys_madvise.do_syscall_64.entry_SYSCALL_64_after_hwframe.__madvise
> 0.62 +0.1 0.70 perf-profile.calltrace.cycles-pp.do_madvise.__x64_sys_madvise.do_syscall_64.entry_SYSCALL_64_after_hwframe.__madvise
> 0.66 +0.1 0.74 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.__madvise
> 0.66 +0.1 0.74 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.__madvise
> 87.74 +0.7 88.45 perf-profile.calltrace.cycles-pp.mremap
> 0.00 +0.9 0.86 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.can_modify_mm.do_vmi_munmap.do_munmap
> 0.00 +0.9 0.86 perf-profile.calltrace.cycles-pp.mas_walk.mas_find.can_modify_mm.mremap_to.__do_sys_mremap
> 84.88 +0.9 85.77 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.mremap
> 84.73 +0.9 85.62 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 0.00 +0.9 0.92 ą 2% perf-profile.calltrace.cycles-pp.mas_walk.mas_find.can_modify_mm.do_vmi_munmap.move_vma
> 83.84 +0.9 84.78 perf-profile.calltrace.cycles-pp.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 0.00 +1.1 1.06 perf-profile.calltrace.cycles-pp.mas_find.can_modify_mm.mremap_to.__do_sys_mremap.do_syscall_64
> 0.00 +1.2 1.21 perf-profile.calltrace.cycles-pp.mas_find.can_modify_mm.do_vmi_munmap.do_munmap.mremap_to
> 2.07 +1.5 3.55 perf-profile.calltrace.cycles-pp.do_munmap.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 1.58 +1.5 3.07 perf-profile.calltrace.cycles-pp.do_vmi_munmap.do_munmap.mremap_to.__do_sys_mremap.do_syscall_64
> 0.00 +1.5 1.52 perf-profile.calltrace.cycles-pp.mas_find.can_modify_mm.do_vmi_munmap.move_vma.__do_sys_mremap
> 0.00 +1.6 1.57 perf-profile.calltrace.cycles-pp.can_modify_mm.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 0.00 +1.7 1.72 perf-profile.calltrace.cycles-pp.can_modify_mm.do_vmi_munmap.do_munmap.mremap_to.__do_sys_mremap
> 0.00 +2.0 2.01 perf-profile.calltrace.cycles-pp.can_modify_mm.do_vmi_munmap.move_vma.__do_sys_mremap.do_syscall_64
> 5.39 +2.9 8.32 perf-profile.calltrace.cycles-pp.mremap_to.__do_sys_mremap.do_syscall_64.entry_SYSCALL_64_after_hwframe.mremap
> 75.29 -1.9 73.37 perf-profile.children.cycles-pp.move_vma
> 37.06 -1.6 35.50 perf-profile.children.cycles-pp.do_vmi_align_munmap
> 24.98 -1.2 23.80 perf-profile.children.cycles-pp.copy_vma
> 19.99 -1.0 19.02 perf-profile.children.cycles-pp.handle_softirqs
> 19.97 -1.0 19.00 perf-profile.children.cycles-pp.rcu_core
> 19.95 -1.0 18.98 perf-profile.children.cycles-pp.rcu_do_batch
> 19.98 -0.9 19.06 perf-profile.children.cycles-pp.__split_vma
> 17.55 -0.8 16.76 perf-profile.children.cycles-pp.kmem_cache_free
> 10.56 ą 2% -0.8 9.79 ą 2% perf-profile.children.cycles-pp.run_ksoftirqd
> 10.57 ą 2% -0.8 9.80 ą 2% perf-profile.children.cycles-pp.smpboot_thread_fn
> 15.38 -0.8 14.62 perf-profile.children.cycles-pp.kmem_cache_alloc_noprof
> 10.62 ą 2% -0.8 9.85 ą 2% perf-profile.children.cycles-pp.kthread
> 10.62 ą 2% -0.8 9.86 ą 2% perf-profile.children.cycles-pp.ret_from_fork
> 10.62 ą 2% -0.8 9.86 ą 2% perf-profile.children.cycles-pp.ret_from_fork_asm
> 15.14 -0.7 14.44 perf-profile.children.cycles-pp.vma_merge
> 12.08 -0.5 11.55 perf-profile.children.cycles-pp.__slab_free
> 12.11 -0.5 11.62 perf-profile.children.cycles-pp.mas_wr_store_entry
> 10.86 -0.5 10.39 perf-profile.children.cycles-pp.vm_area_dup
> 11.89 -0.5 11.44 perf-profile.children.cycles-pp.mas_store_prealloc
> 8.49 -0.4 8.06 perf-profile.children.cycles-pp.__memcg_slab_post_alloc_hook
> 9.88 -0.4 9.49 perf-profile.children.cycles-pp.mas_wr_node_store
> 7.91 -0.3 7.58 perf-profile.children.cycles-pp.move_page_tables
> 6.06 -0.3 5.78 perf-profile.children.cycles-pp.vm_area_free_rcu_cb
> 8.28 -0.3 8.00 perf-profile.children.cycles-pp.unmap_region
> 6.69 -0.3 6.42 perf-profile.children.cycles-pp.vma_complete
> 5.06 -0.3 4.80 perf-profile.children.cycles-pp.mas_preallocate
> 5.82 -0.2 5.57 perf-profile.children.cycles-pp.move_ptes
> 4.24 -0.2 4.01 perf-profile.children.cycles-pp.anon_vma_clone
> 3.50 -0.2 3.30 perf-profile.children.cycles-pp.down_write
> 2.44 -0.2 2.25 perf-profile.children.cycles-pp.find_vma_prev
> 3.46 -0.2 3.28 perf-profile.children.cycles-pp.___slab_alloc
> 3.45 -0.2 3.27 perf-profile.children.cycles-pp.free_pgtables
> 2.54 -0.2 2.37 perf-profile.children.cycles-pp.rcu_cblist_dequeue
> 3.35 -0.2 3.18 perf-profile.children.cycles-pp.__memcg_slab_free_hook
> 2.93 -0.2 2.78 perf-profile.children.cycles-pp.mas_alloc_nodes
> 2.28 ą 2% -0.2 2.12 ą 2% perf-profile.children.cycles-pp.vma_prepare
> 3.46 -0.1 3.32 perf-profile.children.cycles-pp.flush_tlb_mm_range
> 3.41 -0.1 3.27 ą 2% perf-profile.children.cycles-pp.mod_objcg_state
> 2.76 -0.1 2.63 perf-profile.children.cycles-pp.unlink_anon_vmas
> 3.41 -0.1 3.28 perf-profile.children.cycles-pp.mas_store_gfp
> 2.21 -0.1 2.09 perf-profile.children.cycles-pp.__cond_resched
> 2.04 -0.1 1.94 perf-profile.children.cycles-pp.allocate_slab
> 2.10 -0.1 2.00 perf-profile.children.cycles-pp.__call_rcu_common
> 2.51 -0.1 2.40 perf-profile.children.cycles-pp.flush_tlb_func
> 1.04 -0.1 0.94 perf-profile.children.cycles-pp.mas_prev
> 2.71 -0.1 2.61 perf-profile.children.cycles-pp.mtree_load
> 2.23 -0.1 2.14 perf-profile.children.cycles-pp.native_flush_tlb_one_user
> 0.22 ą 5% -0.1 0.13 ą 13% perf-profile.children.cycles-pp.vm_stat_account
> 0.95 -0.1 0.87 perf-profile.children.cycles-pp.mas_prev_setup
> 1.65 -0.1 1.57 perf-profile.children.cycles-pp.mas_wr_walk
> 1.84 -0.1 1.76 perf-profile.children.cycles-pp.up_write
> 1.27 -0.1 1.20 perf-profile.children.cycles-pp.mas_prev_slot
> 1.84 -0.1 1.77 perf-profile.children.cycles-pp.vma_link
> 1.39 -0.1 1.32 perf-profile.children.cycles-pp.shuffle_freelist
> 0.96 -0.1 0.90 ą 2% perf-profile.children.cycles-pp.rcu_all_qs
> 0.86 -0.1 0.80 perf-profile.children.cycles-pp._raw_spin_lock_irqsave
> 1.70 -0.1 1.64 perf-profile.children.cycles-pp.__get_unmapped_area
> 0.34 ą 3% -0.1 0.29 ą 5% perf-profile.children.cycles-pp.security_vm_enough_memory_mm
> 0.60 -0.0 0.55 perf-profile.children.cycles-pp.entry_SYSCALL_64
> 0.92 -0.0 0.87 perf-profile.children.cycles-pp.percpu_counter_add_batch
> 1.07 -0.0 1.02 perf-profile.children.cycles-pp.vma_to_resize
> 1.59 -0.0 1.54 perf-profile.children.cycles-pp.mas_update_gap
> 0.44 ą 2% -0.0 0.40 ą 2% perf-profile.children.cycles-pp.native_queued_spin_lock_slowpath
> 0.70 -0.0 0.66 perf-profile.children.cycles-pp.syscall_return_via_sysret
> 1.13 -0.0 1.09 perf-profile.children.cycles-pp.mt_find
> 0.20 ą 6% -0.0 0.17 ą 9% perf-profile.children.cycles-pp.cap_vm_enough_memory
> 0.99 -0.0 0.95 perf-profile.children.cycles-pp.mas_pop_node
> 0.63 ą 2% -0.0 0.59 perf-profile.children.cycles-pp.security_mmap_addr
> 0.62 -0.0 0.59 perf-profile.children.cycles-pp.__put_partials
> 1.17 -0.0 1.14 perf-profile.children.cycles-pp.clear_bhb_loop
> 0.46 -0.0 0.43 ą 2% perf-profile.children.cycles-pp.__alloc_pages_noprof
> 0.44 -0.0 0.41 ą 2% perf-profile.children.cycles-pp.get_page_from_freelist
> 0.90 -0.0 0.87 perf-profile.children.cycles-pp.userfaultfd_unmap_complete
> 0.64 ą 2% -0.0 0.62 perf-profile.children.cycles-pp.get_old_pud
> 1.07 -0.0 1.05 perf-profile.children.cycles-pp.mas_leaf_max_gap
> 0.22 ą 3% -0.0 0.20 ą 2% perf-profile.children.cycles-pp.__rmqueue_pcplist
> 0.55 -0.0 0.53 perf-profile.children.cycles-pp.refill_obj_stock
> 0.25 -0.0 0.23 ą 3% perf-profile.children.cycles-pp.rmqueue
> 0.48 -0.0 0.45 perf-profile.children.cycles-pp.mremap_userfaultfd_prep
> 0.33 -0.0 0.30 perf-profile.children.cycles-pp.free_unref_page
> 0.46 -0.0 0.44 perf-profile.children.cycles-pp.setup_object
> 0.21 ą 3% -0.0 0.19 ą 2% perf-profile.children.cycles-pp.rmqueue_bulk
> 0.31 ą 3% -0.0 0.29 perf-profile.children.cycles-pp.__vm_enough_memory
> 0.40 -0.0 0.38 perf-profile.children.cycles-pp.entry_SYSRETQ_unsafe_stack
> 0.36 -0.0 0.35 perf-profile.children.cycles-pp.madvise_vma_behavior
> 0.54 -0.0 0.53 ą 2% perf-profile.children.cycles-pp.mas_wr_end_piv
> 0.46 -0.0 0.44 ą 2% perf-profile.children.cycles-pp.rcu_segcblist_enqueue
> 0.34 -0.0 0.32 ą 2% perf-profile.children.cycles-pp.mas_destroy
> 0.28 -0.0 0.26 ą 3% perf-profile.children.cycles-pp.mas_wr_store_setup
> 0.30 -0.0 0.28 perf-profile.children.cycles-pp.pte_offset_map_nolock
> 0.19 -0.0 0.18 ą 2% perf-profile.children.cycles-pp.__thp_vma_allowable_orders
> 0.08 ą 4% -0.0 0.07 perf-profile.children.cycles-pp.ksm_madvise
> 0.17 -0.0 0.16 perf-profile.children.cycles-pp.get_any_partial
> 0.08 -0.0 0.07 perf-profile.children.cycles-pp.syscall_exit_to_user_mode_prepare
> 0.45 +0.0 0.47 perf-profile.children.cycles-pp._raw_spin_lock
> 1.10 +0.0 1.14 perf-profile.children.cycles-pp.zap_pte_range
> 0.78 +0.1 0.85 perf-profile.children.cycles-pp.__madvise
> 0.63 +0.1 0.70 perf-profile.children.cycles-pp.__x64_sys_madvise
> 0.62 +0.1 0.70 perf-profile.children.cycles-pp.do_madvise
> 0.00 +0.1 0.09 ą 4% perf-profile.children.cycles-pp.can_modify_mm_madv
> 1.32 +0.1 1.46 perf-profile.children.cycles-pp.mas_next_slot
> 88.13 +0.7 88.83 perf-profile.children.cycles-pp.mremap
> 83.94 +0.9 84.88 perf-profile.children.cycles-pp.__do_sys_mremap
> 86.06 +0.9 87.00 perf-profile.children.cycles-pp.entry_SYSCALL_64_after_hwframe
> 85.56 +1.0 86.54 perf-profile.children.cycles-pp.do_syscall_64
> 40.49 +1.4 41.90 perf-profile.children.cycles-pp.do_vmi_munmap
> 2.10 +1.5 3.57 perf-profile.children.cycles-pp.do_munmap
> 3.62 +2.3 5.90 perf-profile.children.cycles-pp.mas_walk
> 5.44 +2.9 8.38 perf-profile.children.cycles-pp.mremap_to
> 5.30 +3.1 8.39 perf-profile.children.cycles-pp.mas_find
> 0.00 +5.4 5.40 perf-profile.children.cycles-pp.can_modify_mm
> 11.46 -0.5 10.96 perf-profile.self.cycles-pp.__slab_free
> 4.30 -0.2 4.08 perf-profile.self.cycles-pp.__memcg_slab_post_alloc_hook
> 2.51 -0.2 2.34 perf-profile.self.cycles-pp.rcu_cblist_dequeue
> 2.41 ą 2% -0.2 2.25 perf-profile.self.cycles-pp.down_write
> 2.21 -0.1 2.11 perf-profile.self.cycles-pp.native_flush_tlb_one_user
> 2.37 -0.1 2.28 perf-profile.self.cycles-pp.mtree_load
> 1.60 -0.1 1.51 perf-profile.self.cycles-pp.__memcg_slab_free_hook
> 0.18 ą 3% -0.1 0.10 ą 15% perf-profile.self.cycles-pp.vm_stat_account
> 1.25 -0.1 1.18 perf-profile.self.cycles-pp.move_vma
> 1.76 -0.1 1.69 perf-profile.self.cycles-pp.mod_objcg_state
> 1.42 -0.1 1.35 ą 2% perf-profile.self.cycles-pp.__call_rcu_common
> 1.41 -0.1 1.34 perf-profile.self.cycles-pp.mas_wr_walk
> 1.52 -0.1 1.46 perf-profile.self.cycles-pp.up_write
> 1.02 -0.1 0.95 perf-profile.self.cycles-pp.mas_prev_slot
> 0.96 -0.1 0.90 ą 2% perf-profile.self.cycles-pp.vm_area_free_rcu_cb
> 1.50 -0.1 1.45 perf-profile.self.cycles-pp.kmem_cache_free
> 0.69 ą 3% -0.1 0.64 ą 2% perf-profile.self.cycles-pp.rcu_all_qs
> 1.14 ą 2% -0.1 1.09 perf-profile.self.cycles-pp.shuffle_freelist
> 1.10 -0.1 1.05 perf-profile.self.cycles-pp.__cond_resched
> 1.40 -0.0 1.35 perf-profile.self.cycles-pp.do_vmi_align_munmap
> 0.99 -0.0 0.94 perf-profile.self.cycles-pp.mas_preallocate
> 0.88 -0.0 0.83 perf-profile.self.cycles-pp.___slab_alloc
> 0.55 -0.0 0.50 perf-profile.self.cycles-pp.mremap_to
> 0.98 -0.0 0.93 perf-profile.self.cycles-pp.move_ptes
> 0.78 -0.0 0.74 perf-profile.self.cycles-pp.percpu_counter_add_batch
> 0.21 ą 2% -0.0 0.18 ą 2% perf-profile.self.cycles-pp.entry_SYSCALL_64
> 0.44 ą 2% -0.0 0.40 ą 2% perf-profile.self.cycles-pp.native_queued_spin_lock_slowpath
> 0.92 -0.0 0.89 perf-profile.self.cycles-pp.mas_store_gfp
> 0.86 -0.0 0.82 perf-profile.self.cycles-pp.mas_pop_node
> 0.50 -0.0 0.46 perf-profile.self.cycles-pp.entry_SYSCALL_64_after_hwframe
> 1.15 -0.0 1.12 perf-profile.self.cycles-pp.clear_bhb_loop
> 1.14 -0.0 1.11 perf-profile.self.cycles-pp.vma_merge
> 0.66 -0.0 0.63 perf-profile.self.cycles-pp.__split_vma
> 0.16 ą 6% -0.0 0.13 ą 7% perf-profile.self.cycles-pp.cap_vm_enough_memory
> 0.82 -0.0 0.79 perf-profile.self.cycles-pp.mas_wr_store_entry
> 0.54 ą 2% -0.0 0.52 perf-profile.self.cycles-pp.get_old_pud
> 0.43 -0.0 0.40 perf-profile.self.cycles-pp.do_munmap
> 0.51 ą 2% -0.0 0.48 ą 2% perf-profile.self.cycles-pp.security_mmap_addr
> 0.50 -0.0 0.48 perf-profile.self.cycles-pp.refill_obj_stock
> 0.24 -0.0 0.22 perf-profile.self.cycles-pp.mas_prev
> 0.71 -0.0 0.69 perf-profile.self.cycles-pp.unmap_page_range
> 0.48 -0.0 0.45 perf-profile.self.cycles-pp.find_vma_prev
> 0.42 -0.0 0.40 perf-profile.self.cycles-pp._raw_spin_lock_irqsave
> 0.66 -0.0 0.64 perf-profile.self.cycles-pp.mas_store_prealloc
> 0.31 -0.0 0.29 perf-profile.self.cycles-pp.mas_prev_setup
> 0.43 -0.0 0.41 perf-profile.self.cycles-pp.mas_wr_end_piv
> 0.78 -0.0 0.76 perf-profile.self.cycles-pp.userfaultfd_unmap_complete
> 0.28 -0.0 0.26 ą 2% perf-profile.self.cycles-pp.mas_put_in_tree
> 0.42 -0.0 0.40 perf-profile.self.cycles-pp.mremap_userfaultfd_prep
> 0.28 -0.0 0.26 perf-profile.self.cycles-pp.free_pgtables
> 0.39 -0.0 0.37 perf-profile.self.cycles-pp.entry_SYSRETQ_unsafe_stack
> 0.30 ą 2% -0.0 0.28 perf-profile.self.cycles-pp.zap_pmd_range
> 0.32 -0.0 0.31 perf-profile.self.cycles-pp.unmap_vmas
> 0.21 -0.0 0.20 perf-profile.self.cycles-pp.__get_unmapped_area
> 0.18 ą 2% -0.0 0.17 ą 2% perf-profile.self.cycles-pp.lru_add_drain_cpu
> 0.06 -0.0 0.05 perf-profile.self.cycles-pp.ksm_madvise
> 0.45 +0.0 0.46 perf-profile.self.cycles-pp.do_vmi_munmap
> 0.37 +0.0 0.39 perf-profile.self.cycles-pp._raw_spin_lock
> 1.06 +0.1 1.18 perf-profile.self.cycles-pp.mas_next_slot
> 1.50 +0.5 1.97 perf-profile.self.cycles-pp.mas_find
> 0.00 +1.4 1.35 perf-profile.self.cycles-pp.can_modify_mm
> 3.13 +2.0 5.13 perf-profile.self.cycles-pp.mas_walk
>
>
> ***************************************************************************************************
> lkp-spr-r02: 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 256G memory
> =========================================================================================
> compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime:
> gcc-13/performance/x86_64-rhel-8.3/100%/debian-12-x86_64-20240206.cgz/lkp-spr-r02/pkey/stress-ng/60s
>
> commit:
> ff388fe5c4 ("mseal: wire up mseal syscall")
> 8be7258aad ("mseal: add mseal syscall")
>
> ff388fe5c481d39c 8be7258aad44b5e25977a98db13
> ---------------- ---------------------------
> %stddev %change %stddev
> \ | \
> 10539 -2.5% 10273 vmstat.system.cs
> 0.28 ą 5% -20.1% 0.22 ą 7% sched_debug.cfs_rq:/.h_nr_running.stddev
> 1419 ą 7% -15.3% 1202 ą 6% sched_debug.cfs_rq:/.util_avg.max
> 0.28 ą 6% -18.4% 0.23 ą 8% sched_debug.cpu.nr_running.stddev
> 8.736e+08 -3.6% 8.423e+08 stress-ng.pkey.ops
> 14560560 -3.6% 14038795 stress-ng.pkey.ops_per_sec
> 770.39 ą 4% -5.0% 732.04 stress-ng.time.user_time
> 244657 ą 3% +5.8% 258782 ą 3% proc-vmstat.nr_slab_unreclaimable
> 73133541 -2.1% 71588873 proc-vmstat.numa_hit
> 72873579 -2.1% 71357274 proc-vmstat.numa_local
> 1.842e+08 -2.5% 1.796e+08 proc-vmstat.pgalloc_normal
> 1.767e+08 -2.8% 1.717e+08 proc-vmstat.pgfree
> 1345346 ą 40% -73.1% 362064 ą124% numa-vmstat.node0.nr_inactive_anon
> 1345340 ą 40% -73.1% 362062 ą124% numa-vmstat.node0.nr_zone_inactive_anon
> 2420830 ą 14% +35.1% 3270248 ą 16% numa-vmstat.node1.nr_file_pages
> 2067871 ą 13% +51.5% 3132982 ą 17% numa-vmstat.node1.nr_inactive_anon
> 191406 ą 17% +33.6% 255808 ą 14% numa-vmstat.node1.nr_mapped
> 2452 ą 61% +104.4% 5012 ą 35% numa-vmstat.node1.nr_page_table_pages
> 2067853 ą 13% +51.5% 3132966 ą 17% numa-vmstat.node1.nr_zone_inactive_anon
> 5379238 ą 40% -73.0% 1453605 ą123% numa-meminfo.node0.Inactive
> 5379166 ą 40% -73.0% 1453462 ą123% numa-meminfo.node0.Inactive(anon)
> 8741077 ą 22% -36.7% 5531290 ą 28% numa-meminfo.node0.MemUsed
> 9651902 ą 13% +35.8% 13105318 ą 16% numa-meminfo.node1.FilePages
> 8239855 ą 13% +52.4% 12556929 ą 17% numa-meminfo.node1.Inactive
> 8239712 ą 13% +52.4% 12556853 ą 17% numa-meminfo.node1.Inactive(anon)
> 761944 ą 18% +34.6% 1025906 ą 14% numa-meminfo.node1.Mapped
> 11679628 ą 11% +31.2% 15322841 ą 14% numa-meminfo.node1.MemUsed
> 9874 ą 62% +104.6% 20200 ą 36% numa-meminfo.node1.PageTables
> 0.74 -4.2% 0.71 perf-stat.i.MPKI
> 1.245e+11 +2.3% 1.274e+11 perf-stat.i.branch-instructions
> 0.37 -0.0 0.35 perf-stat.i.branch-miss-rate%
> 4.359e+08 -2.1% 4.265e+08 perf-stat.i.branch-misses
> 4.672e+08 -2.6% 4.548e+08 perf-stat.i.cache-misses
> 7.276e+08 -2.7% 7.082e+08 perf-stat.i.cache-references
> 1.00 -1.6% 0.98 perf-stat.i.cpi
> 1364 +2.9% 1404 perf-stat.i.cycles-between-cache-misses
> 6.392e+11 +1.7% 6.499e+11 perf-stat.i.instructions
> 1.00 +1.6% 1.02 perf-stat.i.ipc
> 0.74 -4.3% 0.71 perf-stat.overall.MPKI
> 0.35 -0.0 0.33 perf-stat.overall.branch-miss-rate%
> 1.00 -1.6% 0.99 perf-stat.overall.cpi
> 1356 +2.9% 1395 perf-stat.overall.cycles-between-cache-misses
> 1.00 +1.6% 1.01 perf-stat.overall.ipc
> 1.209e+11 +1.9% 1.232e+11 perf-stat.ps.branch-instructions
> 4.188e+08 -2.6% 4.077e+08 perf-stat.ps.branch-misses
> 4.585e+08 -3.1% 4.441e+08 perf-stat.ps.cache-misses
> 7.124e+08 -3.1% 6.901e+08 perf-stat.ps.cache-references
> 10321 -2.6% 10053 perf-stat.ps.context-switches
>
>
>
>
>
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
>
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Jeff Xu @ 2024-08-05 17:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: kernel test robot, oe-lkp, lkp, linux-kernel, Andrew Morton,
Kees Cook, Liam R. Howlett, Pedro Falcato, Dave Hansen,
Greg Kroah-Hartman, Guenter Roeck, Jann Horn, Jeff Xu,
Jonathan Corbet, Jorge Lucangeli Obes, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin
In-Reply-To: <CAHk-=whbxLj0thXPzN9aW4CcX1D2_dntNu+x9-8uBakamBggLA@mail.gmail.com>
On Sun, Aug 4, 2024 at 1:33 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sun, 4 Aug 2024 at 01:59, kernel test robot <oliver.sang@intel.com> wrote:
> >
> > kernel test robot noticed a -4.4% regression of stress-ng.pagemove.page_remaps_per_sec on
> > commit 8be7258aad44 ("mseal: add mseal syscall")
>
> Ok, it's basically just the vma walk in can_modify_mm():
>
> > 1.06 +0.1 1.18 perf-profile.self.cycles-pp.mas_next_slot
> > 1.50 +0.5 1.97 perf-profile.self.cycles-pp.mas_find
> > 0.00 +1.4 1.35 perf-profile.self.cycles-pp.can_modify_mm
> > 3.13 +2.0 5.13 perf-profile.self.cycles-pp.mas_walk
>
> and looks like it's two different pathways. We have __do_sys_mremap ->
> mremap_to -> do_munmap -> do_vmi_munmap -> can_modify_mm for the
> destination mapping, but we also have mremap_to() calling
> can_modify_mm() directly for the source mapping.
>
There are two scenarios in mremap syscall.
1> mremap_to (relocate vma)
2> shrink/expand.
Those two scenarios are handled by different code path:
For case 1>
mremap_to (relocate vma)
-> can_modify_mm , check src for sealing.
-> if MREMAP_FIXED
->-> do_munmap (dst) // free dst
->->-> do_vmi_munmap (dst)
->->->-> can_modify_mm (dst) // check dst for sealing
-> if dst size is smaller (shrink case)
->-> do_munmap(dst, to remove extra size)
->->-> do_vmi_munmap
->->->-> can_modify_mm(dst) (potentially duplicate with check for
MREMAP_FIXED, practically, the memory should be unmapped, so the cost
looking for a un-existed memory range in the maple tree )
For case 2>
Shrink/Expand.
-> can_modify_mm, check addr is sealed
-> if dst size is smaller (shrink case)
->-> do_vmi_munmap(remove_extra_size)
-> ->-> can_modify_mm(addr) (This is redundant because addr is already checked)
For case 2:, potentially we can improve it by passing a flag into
do_vmi_munmap() to indicate the sealing is already checked by the
caller. (however, this idea have to be tested to show actual gain)
The reported regression is in mremap, I wonder why mprotect/munmap
doesn't have similar impact, since they use the same pattern (one
extra out-of-place check for memory range)
During version 9, I tested munmap/mprotect/madvise for perf [1] . The
test shows mseal adds 20-40 ns or 50-100 CPU cycle pre call, this is
much smaller (one tenth) than change from 5.10 to 6.8. The test is
using multiple VMAs with various types[2]. The next step for me is
to run the stress-ng.pagemove.page_remaps_per_sec to understand why
mremap shows a big regression number.
[1] https://lore.kernel.org/all/20240214151130.616240-1-jeffxu@chromium.org/
[2] https://github.com/peaktocreek/mmperf
Best regards,
-Jeff
> And then do_vmi_munmap() will do it's *own* vma_find() after having
> done arch_unmap().
>
> And do_munmap() will obviously do its own vma lookup as part of
> calling vma_to_resize().
>
> So it looks like a large portion of this regression is because the
> mseal addition just ends up walking the vma list way too much.
>
> Linus
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Jeff Xu @ 2024-08-05 18:10 UTC (permalink / raw)
To: Pedro Falcato
Cc: Linus Torvalds, kernel test robot, Jeff Xu, oe-lkp, lkp,
linux-kernel, Andrew Morton, Kees Cook, Liam R. Howlett,
Dave Hansen, Greg Kroah-Hartman, Guenter Roeck, Jann Horn,
Jonathan Corbet, Jorge Lucangeli Obes, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin
In-Reply-To: <CAKbZUD3B03Zjex4STW8J_1VJhpsYb=1mnZL2-vSaW-CaZdzLiA@mail.gmail.com>
On Mon, Aug 5, 2024 at 6:33 AM Pedro Falcato <pedro.falcato@gmail.com> wrote:
>
> On Sun, Aug 4, 2024 at 9:33 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Sun, 4 Aug 2024 at 01:59, kernel test robot <oliver.sang@intel.com> wrote:
> > >
> > > kernel test robot noticed a -4.4% regression of stress-ng.pagemove.page_remaps_per_sec on
> > > commit 8be7258aad44 ("mseal: add mseal syscall")
> >
> > Ok, it's basically just the vma walk in can_modify_mm():
> >
> > > 1.06 +0.1 1.18 perf-profile.self.cycles-pp.mas_next_slot
> > > 1.50 +0.5 1.97 perf-profile.self.cycles-pp.mas_find
> > > 0.00 +1.4 1.35 perf-profile.self.cycles-pp.can_modify_mm
> > > 3.13 +2.0 5.13 perf-profile.self.cycles-pp.mas_walk
> >
> > and looks like it's two different pathways. We have __do_sys_mremap ->
> > mremap_to -> do_munmap -> do_vmi_munmap -> can_modify_mm for the
> > destination mapping, but we also have mremap_to() calling
> > can_modify_mm() directly for the source mapping.
> >
> > And then do_vmi_munmap() will do it's *own* vma_find() after having
> > done arch_unmap().
> >
> > And do_munmap() will obviously do its own vma lookup as part of
> > calling vma_to_resize().
> >
> > So it looks like a large portion of this regression is because the
> > mseal addition just ends up walking the vma list way too much.
>
> Can we rollback the upfront checks "funny business" and just call
> can_modify_vma directly in relevant places? I still don't believe in
> the partial mprotect/munmap "security risks" that were stated in the
> mseal thread (and these operations can already fail for many other
> reasons than mseal) :)
>
In-place check and extra loop, implemented properly, will both prevent
changing to the sealed memory.
However, extra loop will make attacker difficult to call munmap(0,
random large-size), because if one of vma in the range is sealed, the
whole operation will be no-op.
> I don't mind taking a look myself, just want to make sure I'm not
> stepping on anyone's toes here.
>
One thing that you can't walk around is that can_modify_mm must be
called prior to arch_unmap, that means in-place check for the munmap
is not possible.
( There are recent patch / refactor by Liam R. Howlett in this area,
but I am not sure if this restriction is removed)
> --
> Pedro
^ permalink raw reply
* Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
From: Jeff Xu @ 2024-08-05 18:35 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Al Viro, Christian Brauner, Kees Cook, Linus Torvalds, Paul Moore,
Theodore Ts'o, Alejandro Colomar, Aleksa Sarai, Andrew Morton,
Andy Lutomirski, Arnd Bergmann, Casey Schaufler, Christian Heimes,
Dmitry Vyukov, Eric Biggers, Eric Chiang, Fan Wu, Florian Weimer,
Geert Uytterhoeven, James Morris, Jan Kara, Jann Horn,
Jonathan Corbet, Jordan R Abrahams, Lakshmi Ramasubramanian,
Luca Boccassi, Luis Chamberlain, Madhavan T . Venkataraman,
Matt Bobrowski, Matthew Garrett, Matthew Wilcox, Miklos Szeredi,
Mimi Zohar, Nicolas Bouchinet, Scott Shell, Shuah Khan,
Stephen Rothwell, Steve Dower, Steve Grubb, Thibaut Sautereau,
Vincent Strubel, Xiaoming Ni, Yin Fengwei, kernel-hardening,
linux-api, linux-fsdevel, linux-integrity, linux-kernel,
linux-security-module, Elliott Hughes
In-Reply-To: <20240723.beiTu0qui2ei@digikod.net>
On Tue, Jul 23, 2024 at 6:15 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> On Fri, Jul 19, 2024 at 08:27:18AM -0700, Jeff Xu wrote:
> > On Fri, Jul 19, 2024 at 8:04 AM Mickaël Salaün <mic@digikod.net> wrote:
> > >
> > > On Fri, Jul 19, 2024 at 07:16:55AM -0700, Jeff Xu wrote:
> > > > On Fri, Jul 19, 2024 at 1:45 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > >
> > > > > On Thu, Jul 18, 2024 at 06:29:54PM -0700, Jeff Xu wrote:
> > > > > > On Thu, Jul 18, 2024 at 5:24 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > >
> > > > > > > On Wed, Jul 17, 2024 at 07:08:17PM -0700, Jeff Xu wrote:
> > > > > > > > On Wed, Jul 17, 2024 at 3:01 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Jul 16, 2024 at 11:33:55PM -0700, Jeff Xu wrote:
> > > > > > > > > > On Thu, Jul 4, 2024 at 12:02 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Add a new AT_CHECK flag to execveat(2) to check if a file would be
> > > > > > > > > > > allowed for execution. The main use case is for script interpreters and
> > > > > > > > > > > dynamic linkers to check execution permission according to the kernel's
> > > > > > > > > > > security policy. Another use case is to add context to access logs e.g.,
> > > > > > > > > > > which script (instead of interpreter) accessed a file. As any
> > > > > > > > > > > executable code, scripts could also use this check [1].
> > > > > > > > > > >
> > > > > > > > > > > This is different than faccessat(2) which only checks file access
> > > > > > > > > > > rights, but not the full context e.g. mount point's noexec, stack limit,
> > > > > > > > > > > and all potential LSM extra checks (e.g. argv, envp, credentials).
> > > > > > > > > > > Since the use of AT_CHECK follows the exact kernel semantic as for a
> > > > > > > > > > > real execution, user space gets the same error codes.
> > > > > > > > > > >
> > > > > > > > > > So we concluded that execveat(AT_CHECK) will be used to check the
> > > > > > > > > > exec, shared object, script and config file (such as seccomp config),
> > > > >
> > > > > > > > > > I think binfmt_elf.c in the kernel needs to check the ld.so to make
> > > > > > > > > > sure it passes AT_CHECK, before loading it into memory.
> > > > > > > > >
> > > > > > > > > All ELF dependencies are opened and checked with open_exec(), which
> > > > > > > > > perform the main executability checks (with the __FMODE_EXEC flag).
> > > > > > > > > Did I miss something?
> > > > > > > > >
> > > > > > > > I mean the ld-linux-x86-64.so.2 which is loaded by binfmt in the kernel.
> > > > > > > > The app can choose its own dynamic linker path during build, (maybe
> > > > > > > > even statically link one ?) This is another reason that relying on a
> > > > > > > > userspace only is not enough.
> > > > > > >
> > > > > > > The kernel calls open_exec() on all dependencies, including
> > > > > > > ld-linux-x86-64.so.2, so these files are checked for executability too.
> > > > > > >
> > > > > > This might not be entirely true. iiuc, kernel calls open_exec for
> > > > > > open_exec for interpreter, but not all its dependency (e.g. libc.so.6)
> > > > >
> > > > > Correct, the dynamic linker is in charge of that, which is why it must
> > > > > be enlighten with execveat+AT_CHECK and securebits checks.
> > > > >
> > > > > > load_elf_binary() {
> > > > > > interpreter = open_exec(elf_interpreter);
> > > > > > }
> > > > > >
> > > > > > libc.so.6 is opened and mapped by dynamic linker.
> > > > > > so the call sequence is:
> > > > > > execve(a.out)
> > > > > > - open exec(a.out)
> > > > > > - security_bprm_creds(a.out)
> > > > > > - open the exec(ld.so)
> > > > > > - call open_exec() for interruptor (ld.so)
> > > > > > - call execveat(AT_CHECK, ld.so) <-- do we want ld.so going through
> > > > > > the same check and code path as libc.so below ?
> > > > >
> > > > > open_exec() checks are enough. LSMs can use this information (open +
> > > > > __FMODE_EXEC) if needed. execveat+AT_CHECK is only a user space
> > > > > request.
> > > > >
> > > > Then the ld.so doesn't go through the same security_bprm_creds() check
> > > > as other .so.
> > >
> > > Indeed, but...
> > >
> > My point is: we will want all the .so going through the same code
> > path, so security_ functions are called consistently across all the
> > objects, And in the future, if we want to develop additional LSM
> > functionality based on AT_CHECK, it will be applied to all objects.
>
> I'll extend the doc to encourage LSMs to check for __FMODE_EXEC, which
> already is the common security check for all executable dependencies.
> As extra information, they can get explicit requests by looking at
> execveat+AT_CHECK call.
>
I agree that security_file_open + __FMODE_EXEC for checking all
the .so (e.g for executable memfd) is a better option than checking at
security_bprm_creds_for_exec.
But then maybe execveat( AT_CHECK) can return after calling alloc_bprm ?
See below call graph:
do_execveat_common (AT_CHECK)
-> alloc_bprm
->->do_open_execat
->->-> do_filp_open (__FMODE_EXEC)
->->->->->->> security_file_open
-> bprm_execve
->-> prepare_exec_creds
->->-> prepare_creds
->->->-> security_prepare_creds
->-> security_bprm_creds_for_exec
What is the consideration to mark the end at
security_bprm_creds_for_exec ? i.e. including brpm_execve,
prepare_creds, security_prepare_creds, security_bprm_creds_for_exec.
Since dynamic linker doesn't load ld.so (it is by kernel), ld.so
won't go through those security_prepare_creds and
security_bprm_creds_for_exec checks like other .so do.
> >
> > Another thing to consider is: we are asking userspace to make
> > additional syscall before loading the file into memory/get executed,
> > there is a possibility for future expansion of the mechanism, without
> > asking user space to add another syscall again.
>
> AT_CHECK is defined with a specific semantic. Other mechanisms (e.g.
> LSM policies) could enforce other restrictions following the same
> semantic. We need to keep in mind backward compatibility.
>
> >
> > I m still not convinced yet that execveat(AT_CHECK) fits more than
> > faccessat(AT_CHECK)
>
> faccessat2(2) is dedicated to file permission/attribute check.
> execveat(2) is dedicated to execution, which is a superset of file
> permission for executability, plus other checks (e.g. noexec).
>
That sounds reasonable, but if execveat(AT_CHECK) changes behavior of
execveat(), someone might argue that faccessat2(EXEC_CHECK) can be
made for the executability.
I think the decision might depend on what this PATCH intended to
check, i.e. where we draw the line.
do_open_execat() seems to cover lots of checks for executability, if
we are ok with the thing that do_open_execat() checks, then
faccessat(AT_CHECK) calling do_open_execat() is an option, it won't
have those "unrelated" calls in execve path, e.g. bprm_stack_limits,
copy argc/env .
However, you mentioned superset of file permission for executability,
can you elaborate on that ? Is there something not included in
do_open_execat() but still necessary for execveat(AT_CHECK)? maybe
security_bprm_creds_for_exec? (this goes back to my question above)
Thanks
Best regards,
-Jeff
> >
> >
> > > >
> > > > As my previous email, the ChromeOS LSM restricts executable mfd
> > > > through security_bprm_creds(), the end result is that ld.so can still
> > > > be executable memfd, but not other .so.
> > >
> > > The chromeOS LSM can check that with the security_file_open() hook and
> > > the __FMODE_EXEC flag, see Landlock's implementation. I think this
> > > should be the only hook implementation that chromeOS LSM needs to add.
> > >
> > > >
> > > > One way to address this is to refactor the necessary code from
> > > > execveat() code patch, and make it available to call from both kernel
> > > > and execveat() code paths., but if we do that, we might as well use
> > > > faccessat2(AT_CHECK)
> > >
> > > That's why I think it makes sense to rely on the existing __FMODE_EXEC
> > > information.
> > >
> > > >
> > > >
> > > > > > - transfer the control to ld.so)
> > > > > > - ld.so open (libc.so)
> > > > > > - ld.so call execveat(AT_CHECK,libc.so) <-- proposed by this patch,
> > > > > > require dynamic linker change.
> > > > > > - ld.so mmap(libc.so,rx)
> > > > >
> > > > > Explaining these steps is useful. I'll include that in the next patch
> > > > > series.
> >
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Linus Torvalds @ 2024-08-05 18:55 UTC (permalink / raw)
To: Jeff Xu, Michael Ellerman, Nicholas Piggin, Christophe Leroy
Cc: Pedro Falcato, kernel test robot, Jeff Xu, oe-lkp, lkp,
linux-kernel, Andrew Morton, Kees Cook, Liam R. Howlett,
Dave Hansen, Greg Kroah-Hartman, Guenter Roeck, Jann Horn,
Jonathan Corbet, Jorge Lucangeli Obes, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin
In-Reply-To: <CALmYWFuXVCvAfrcDOCAR72z2_rmnm09QeVVqdhzqjF-fZ9ndUA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]
On Mon, 5 Aug 2024 at 11:11, Jeff Xu <jeffxu@google.com> wrote:
>
> One thing that you can't walk around is that can_modify_mm must be
> called prior to arch_unmap, that means in-place check for the munmap
> is not possible.
Actually, we should move 'arch_unmap()'.
There is only one user of it, and it's pretty pointless.
(Ok, there are two users - x86 also has an 'arch_unmap()', but it's empty).
The reason I say that the current user of arch_unmap() is pointless is
because this is what the powerpc user does:
static inline void arch_unmap(struct mm_struct *mm,
unsigned long start, unsigned long end)
{
unsigned long vdso_base = (unsigned long)mm->context.vdso;
if (start <= vdso_base && vdso_base < end)
mm->context.vdso = NULL;
}
and that would make sense if we didn't have an actual 'vma' that
matched the vdso. But we do.
I think this code may predate the whole "create a vma for the vdso"
code. Or maybe it was just always confused.
Anyway, what the code *should* do is that we should just have a
->close() function for special mappings, and call that in
special_mapping_close().
This is an ENTIRELY UNTESTED patch that gets rid of this horrendous wart.
Michael / Nick / Christophe? Note that I didn't even compile-test this
on x86-64, much less on powerpc.
So please consider this a "maybe something like this" patch, but that
'arch_unmap()' really is pretty nasty.
Oh, and there was a bug in the error path of the powerpc vdso setup
code anyway. The patch fixes that too, although considering the
entirely untested nature of it, the "fixes" is laughably optimistic.
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 6309 bytes --]
arch/powerpc/include/asm/mmu_context.h | 9 ---------
arch/powerpc/kernel/vdso.c | 12 +++++++++++-
arch/x86/include/asm/mmu_context.h | 5 -----
include/asm-generic/mm_hooks.h | 11 +++--------
include/linux/mm_types.h | 2 ++
mm/mmap.c | 15 ++++++---------
6 files changed, 22 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index 37bffa0f7918..a334a1368848 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -260,15 +260,6 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
extern void arch_exit_mmap(struct mm_struct *mm);
-static inline void arch_unmap(struct mm_struct *mm,
- unsigned long start, unsigned long end)
-{
- unsigned long vdso_base = (unsigned long)mm->context.vdso;
-
- if (start <= vdso_base && vdso_base < end)
- mm->context.vdso = NULL;
-}
-
#ifdef CONFIG_PPC_MEM_KEYS
bool arch_vma_access_permitted(struct vm_area_struct *vma, bool write,
bool execute, bool foreign);
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 7a2ff9010f17..4de8af43f920 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -81,12 +81,20 @@ static int vdso64_mremap(const struct vm_special_mapping *sm, struct vm_area_str
return vdso_mremap(sm, new_vma, &vdso64_end - &vdso64_start);
}
+static int vvar_close(const struct vm_special_mapping *sm,
+ struct vm_area_struct *vma)
+{
+ struct mm_struct *mm = vma->vm_mm;
+ mm->context.vdso = NULL;
+}
+
static vm_fault_t vvar_fault(const struct vm_special_mapping *sm,
struct vm_area_struct *vma, struct vm_fault *vmf);
static struct vm_special_mapping vvar_spec __ro_after_init = {
.name = "[vvar]",
.fault = vvar_fault,
+ .close = vvar_close,
};
static struct vm_special_mapping vdso32_spec __ro_after_init = {
@@ -207,8 +215,10 @@ static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_int
vma = _install_special_mapping(mm, vdso_base, vvar_size,
VM_READ | VM_MAYREAD | VM_IO |
VM_DONTDUMP | VM_PFNMAP, &vvar_spec);
- if (IS_ERR(vma))
+ if (IS_ERR(vma)) {
+ mm->context.vdso = NULL;
return PTR_ERR(vma);
+ }
/*
* our vma flags don't have VM_WRITE so by default, the process isn't
diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
index 8dac45a2c7fc..80f2a3187aa6 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -232,11 +232,6 @@ static inline bool is_64bit_mm(struct mm_struct *mm)
}
#endif
-static inline void arch_unmap(struct mm_struct *mm, unsigned long start,
- unsigned long end)
-{
-}
-
/*
* We only want to enforce protection keys on the current process
* because we effectively have no access to PKRU for other
diff --git a/include/asm-generic/mm_hooks.h b/include/asm-generic/mm_hooks.h
index 4dbb177d1150..6eea3b3c1e65 100644
--- a/include/asm-generic/mm_hooks.h
+++ b/include/asm-generic/mm_hooks.h
@@ -1,8 +1,8 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
- * Define generic no-op hooks for arch_dup_mmap, arch_exit_mmap
- * and arch_unmap to be included in asm-FOO/mmu_context.h for any
- * arch FOO which doesn't need to hook these.
+ * Define generic no-op hooks for arch_dup_mmap and arch_exit_mmap
+ * to be included in asm-FOO/mmu_context.h for any arch FOO which
+ * doesn't need to hook these.
*/
#ifndef _ASM_GENERIC_MM_HOOKS_H
#define _ASM_GENERIC_MM_HOOKS_H
@@ -17,11 +17,6 @@ static inline void arch_exit_mmap(struct mm_struct *mm)
{
}
-static inline void arch_unmap(struct mm_struct *mm,
- unsigned long start, unsigned long end)
-{
-}
-
static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
bool write, bool execute, bool foreign)
{
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 485424979254..ef32d87a3adc 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -1313,6 +1313,8 @@ struct vm_special_mapping {
int (*mremap)(const struct vm_special_mapping *sm,
struct vm_area_struct *new_vma);
+ void (*close)(const struct vm_special_mapping *sm,
+ struct vm_area_struct *vma);
};
enum tlb_flush_reason {
diff --git a/mm/mmap.c b/mm/mmap.c
index d0dfc85b209b..adaaf1ef197a 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2789,7 +2789,7 @@ do_vmi_align_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma,
*
* This function takes a @mas that is either pointing to the previous VMA or set
* to MA_START and sets it up to remove the mapping(s). The @len will be
- * aligned and any arch_unmap work will be preformed.
+ * aligned.
*
* Return: 0 on success and drops the lock if so directed, error and leaves the
* lock held otherwise.
@@ -2809,16 +2809,12 @@ int do_vmi_munmap(struct vma_iterator *vmi, struct mm_struct *mm,
return -EINVAL;
/*
- * Check if memory is sealed before arch_unmap.
- * Prevent unmapping a sealed VMA.
+ * Check if memory is sealed, prevent unmapping a sealed VMA.
* can_modify_mm assumes we have acquired the lock on MM.
*/
if (unlikely(!can_modify_mm(mm, start, end)))
return -EPERM;
- /* arch_unmap() might do unmaps itself. */
- arch_unmap(mm, start, end);
-
/* Find the first overlapping VMA */
vma = vma_find(vmi, end);
if (!vma) {
@@ -3232,14 +3228,12 @@ int do_vma_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma,
struct mm_struct *mm = vma->vm_mm;
/*
- * Check if memory is sealed before arch_unmap.
- * Prevent unmapping a sealed VMA.
+ * Check if memory is sealed, prevent unmapping a sealed VMA.
* can_modify_mm assumes we have acquired the lock on MM.
*/
if (unlikely(!can_modify_mm(mm, start, end)))
return -EPERM;
- arch_unmap(mm, start, end);
return do_vmi_align_munmap(vmi, vma, mm, start, end, uf, unlock);
}
@@ -3624,6 +3618,9 @@ static vm_fault_t special_mapping_fault(struct vm_fault *vmf);
*/
static void special_mapping_close(struct vm_area_struct *vma)
{
+ const struct vm_special_mapping *sm = vma->vm_private_data;
+ if (sm->close)
+ sm->close(sm, vma);
}
static const char *special_mapping_name(struct vm_area_struct *vma)
^ permalink raw reply related
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Linus Torvalds @ 2024-08-05 19:33 UTC (permalink / raw)
To: Jeff Xu, Michael Ellerman, Nicholas Piggin, Christophe Leroy
Cc: Pedro Falcato, kernel test robot, Jeff Xu, oe-lkp, lkp,
linux-kernel, Andrew Morton, Kees Cook, Liam R. Howlett,
Dave Hansen, Greg Kroah-Hartman, Guenter Roeck, Jann Horn,
Jonathan Corbet, Jorge Lucangeli Obes, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin
In-Reply-To: <CAHk-=wgPHCJ0vZMfEP50VPjSVi-CzL0fhTGXgNLQn=Pp9W0DVA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
On Mon, 5 Aug 2024 at 11:55, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So please consider this a "maybe something like this" patch, but that
> 'arch_unmap()' really is pretty nasty
Actually, the whole powerpc vdso code confused me. It's not the vvar
thing that wants this close thing, it's the other ones that have the
remap thing.
.. and there were two of those error cases that needed to reset the
vdso pointer.
That all shows just how carefully I was reading this code.
New version - still untested, but now I've read through it one more
time - attached.
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 6923 bytes --]
arch/powerpc/include/asm/mmu_context.h | 9 ---------
arch/powerpc/kernel/vdso.c | 17 +++++++++++++++--
arch/x86/include/asm/mmu_context.h | 5 -----
include/asm-generic/mm_hooks.h | 11 +++--------
include/linux/mm_types.h | 2 ++
mm/mmap.c | 15 ++++++---------
6 files changed, 26 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index 37bffa0f7918..a334a1368848 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -260,15 +260,6 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
extern void arch_exit_mmap(struct mm_struct *mm);
-static inline void arch_unmap(struct mm_struct *mm,
- unsigned long start, unsigned long end)
-{
- unsigned long vdso_base = (unsigned long)mm->context.vdso;
-
- if (start <= vdso_base && vdso_base < end)
- mm->context.vdso = NULL;
-}
-
#ifdef CONFIG_PPC_MEM_KEYS
bool arch_vma_access_permitted(struct vm_area_struct *vma, bool write,
bool execute, bool foreign);
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 7a2ff9010f17..6fa041a6690a 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -81,6 +81,13 @@ static int vdso64_mremap(const struct vm_special_mapping *sm, struct vm_area_str
return vdso_mremap(sm, new_vma, &vdso64_end - &vdso64_start);
}
+static int vvar_close(const struct vm_special_mapping *sm,
+ struct vm_area_struct *vma)
+{
+ struct mm_struct *mm = vma->vm_mm;
+ mm->context.vdso = NULL;
+}
+
static vm_fault_t vvar_fault(const struct vm_special_mapping *sm,
struct vm_area_struct *vma, struct vm_fault *vmf);
@@ -92,11 +99,13 @@ static struct vm_special_mapping vvar_spec __ro_after_init = {
static struct vm_special_mapping vdso32_spec __ro_after_init = {
.name = "[vdso]",
.mremap = vdso32_mremap,
+ .close = vvar_close,
};
static struct vm_special_mapping vdso64_spec __ro_after_init = {
.name = "[vdso]",
.mremap = vdso64_mremap,
+ .close = vvar_close,
};
#ifdef CONFIG_TIME_NS
@@ -207,8 +216,10 @@ static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_int
vma = _install_special_mapping(mm, vdso_base, vvar_size,
VM_READ | VM_MAYREAD | VM_IO |
VM_DONTDUMP | VM_PFNMAP, &vvar_spec);
- if (IS_ERR(vma))
+ if (IS_ERR(vma)) {
+ mm->context.vdso = NULL;
return PTR_ERR(vma);
+ }
/*
* our vma flags don't have VM_WRITE so by default, the process isn't
@@ -223,8 +234,10 @@ static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_int
vma = _install_special_mapping(mm, vdso_base + vvar_size, vdso_size,
VM_READ | VM_EXEC | VM_MAYREAD |
VM_MAYWRITE | VM_MAYEXEC, vdso_spec);
- if (IS_ERR(vma))
+ if (IS_ERR(vma)) {
+ mm->context.vdso = NULL;
do_munmap(mm, vdso_base, vvar_size, NULL);
+ }
return PTR_ERR_OR_ZERO(vma);
}
diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
index 8dac45a2c7fc..80f2a3187aa6 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -232,11 +232,6 @@ static inline bool is_64bit_mm(struct mm_struct *mm)
}
#endif
-static inline void arch_unmap(struct mm_struct *mm, unsigned long start,
- unsigned long end)
-{
-}
-
/*
* We only want to enforce protection keys on the current process
* because we effectively have no access to PKRU for other
diff --git a/include/asm-generic/mm_hooks.h b/include/asm-generic/mm_hooks.h
index 4dbb177d1150..6eea3b3c1e65 100644
--- a/include/asm-generic/mm_hooks.h
+++ b/include/asm-generic/mm_hooks.h
@@ -1,8 +1,8 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
- * Define generic no-op hooks for arch_dup_mmap, arch_exit_mmap
- * and arch_unmap to be included in asm-FOO/mmu_context.h for any
- * arch FOO which doesn't need to hook these.
+ * Define generic no-op hooks for arch_dup_mmap and arch_exit_mmap
+ * to be included in asm-FOO/mmu_context.h for any arch FOO which
+ * doesn't need to hook these.
*/
#ifndef _ASM_GENERIC_MM_HOOKS_H
#define _ASM_GENERIC_MM_HOOKS_H
@@ -17,11 +17,6 @@ static inline void arch_exit_mmap(struct mm_struct *mm)
{
}
-static inline void arch_unmap(struct mm_struct *mm,
- unsigned long start, unsigned long end)
-{
-}
-
static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
bool write, bool execute, bool foreign)
{
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 485424979254..ef32d87a3adc 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -1313,6 +1313,8 @@ struct vm_special_mapping {
int (*mremap)(const struct vm_special_mapping *sm,
struct vm_area_struct *new_vma);
+ void (*close)(const struct vm_special_mapping *sm,
+ struct vm_area_struct *vma);
};
enum tlb_flush_reason {
diff --git a/mm/mmap.c b/mm/mmap.c
index d0dfc85b209b..adaaf1ef197a 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2789,7 +2789,7 @@ do_vmi_align_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma,
*
* This function takes a @mas that is either pointing to the previous VMA or set
* to MA_START and sets it up to remove the mapping(s). The @len will be
- * aligned and any arch_unmap work will be preformed.
+ * aligned.
*
* Return: 0 on success and drops the lock if so directed, error and leaves the
* lock held otherwise.
@@ -2809,16 +2809,12 @@ int do_vmi_munmap(struct vma_iterator *vmi, struct mm_struct *mm,
return -EINVAL;
/*
- * Check if memory is sealed before arch_unmap.
- * Prevent unmapping a sealed VMA.
+ * Check if memory is sealed, prevent unmapping a sealed VMA.
* can_modify_mm assumes we have acquired the lock on MM.
*/
if (unlikely(!can_modify_mm(mm, start, end)))
return -EPERM;
- /* arch_unmap() might do unmaps itself. */
- arch_unmap(mm, start, end);
-
/* Find the first overlapping VMA */
vma = vma_find(vmi, end);
if (!vma) {
@@ -3232,14 +3228,12 @@ int do_vma_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma,
struct mm_struct *mm = vma->vm_mm;
/*
- * Check if memory is sealed before arch_unmap.
- * Prevent unmapping a sealed VMA.
+ * Check if memory is sealed, prevent unmapping a sealed VMA.
* can_modify_mm assumes we have acquired the lock on MM.
*/
if (unlikely(!can_modify_mm(mm, start, end)))
return -EPERM;
- arch_unmap(mm, start, end);
return do_vmi_align_munmap(vmi, vma, mm, start, end, uf, unlock);
}
@@ -3624,6 +3618,9 @@ static vm_fault_t special_mapping_fault(struct vm_fault *vmf);
*/
static void special_mapping_close(struct vm_area_struct *vma)
{
+ const struct vm_special_mapping *sm = vma->vm_private_data;
+ if (sm->close)
+ sm->close(sm, vma);
}
static const char *special_mapping_name(struct vm_area_struct *vma)
^ permalink raw reply related
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Jeff Xu @ 2024-08-05 19:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Pedro Falcato, kernel test robot, Jeff Xu, oe-lkp, lkp,
linux-kernel, Andrew Morton, Kees Cook, Liam R. Howlett,
Dave Hansen, Greg Kroah-Hartman, Guenter Roeck, Jann Horn,
Jonathan Corbet, Jorge Lucangeli Obes, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin
In-Reply-To: <CAHk-=wgPHCJ0vZMfEP50VPjSVi-CzL0fhTGXgNLQn=Pp9W0DVA@mail.gmail.com>
On Mon, Aug 5, 2024 at 12:01 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, 5 Aug 2024 at 11:11, Jeff Xu <jeffxu@google.com> wrote:
> >
> > One thing that you can't walk around is that can_modify_mm must be
> > called prior to arch_unmap, that means in-place check for the munmap
> > is not possible.
>
> Actually, we should move 'arch_unmap()'.
>
I think you meant "remove"
> There is only one user of it, and it's pretty pointless.
>
> (Ok, there are two users - x86 also has an 'arch_unmap()', but it's empty).
>
> The reason I say that the current user of arch_unmap() is pointless is
> because this is what the powerpc user does:
>
> static inline void arch_unmap(struct mm_struct *mm,
> unsigned long start, unsigned long end)
> {
> unsigned long vdso_base = (unsigned long)mm->context.vdso;
>
> if (start <= vdso_base && vdso_base < end)
> mm->context.vdso = NULL;
> }
>
> and that would make sense if we didn't have an actual 'vma' that
> matched the vdso. But we do.
>
> I think this code may predate the whole "create a vma for the vdso"
> code. Or maybe it was just always confused.
>
Agree it is best to remove.
> Anyway, what the code *should* do is that we should just have a
> ->close() function for special mappings, and call that in
> special_mapping_close().
>
I'm curious, why does ppc need to unmap vdso ? ( other archs don't
have unmap logic.)
vdso has .remap, iiuc, that is for CHECKPOINT_RESTORE feature, i.e.
during restore, vdso might get relocated after taking from dump. [1]
IIUC, vdso mapping doesn't change during the lifetime of the process.
Or does it in some user cases ?
[1] https://lore.kernel.org/linux-mm/20161101172214.2938-1-dsafonov@virtuozzo.com/
> This is an ENTIRELY UNTESTED patch that gets rid of this horrendous wart.
>
> Michael / Nick / Christophe? Note that I didn't even compile-test this
> on x86-64, much less on powerpc.
>
> So please consider this a "maybe something like this" patch, but that
> 'arch_unmap()' really is pretty nasty.
>
> Oh, and there was a bug in the error path of the powerpc vdso setup
> code anyway. The patch fixes that too, although considering the
> entirely untested nature of it, the "fixes" is laughably optimistic.
>
> Linus
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Linus Torvalds @ 2024-08-05 19:48 UTC (permalink / raw)
To: Jeff Xu
Cc: Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Pedro Falcato, kernel test robot, Jeff Xu, oe-lkp, lkp,
linux-kernel, Andrew Morton, Kees Cook, Liam R. Howlett,
Dave Hansen, Greg Kroah-Hartman, Guenter Roeck, Jann Horn,
Jonathan Corbet, Jorge Lucangeli Obes, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin
In-Reply-To: <CALmYWFuCvphvLQOuQHBbFq0G8Ekyze=q45Tt4dATOt-GhO2RGg@mail.gmail.com>
On Mon, 5 Aug 2024 at 12:38, Jeff Xu <jeffxu@google.com> wrote:
>
> I'm curious, why does ppc need to unmap vdso ? ( other archs don't
> have unmap logic.)
I have no idea. There are comments about 'perf' getting confused about
mmap counts when 'context.vdso' isn't set up.
But x86 has the same context.vdso logic, and does *not* set the
pointer before installing the vma, for example. Also does not zero it
out on munmap(), although it does have the mremap logic.
For all I know it may all be entirely unnecessary, and could be
removed entirely.
Linus
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Linus Torvalds @ 2024-08-05 19:50 UTC (permalink / raw)
To: Jeff Xu
Cc: Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Pedro Falcato, kernel test robot, Jeff Xu, oe-lkp, lkp,
linux-kernel, Andrew Morton, Kees Cook, Liam R. Howlett,
Dave Hansen, Greg Kroah-Hartman, Guenter Roeck, Jann Horn,
Jonathan Corbet, Jorge Lucangeli Obes, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin
In-Reply-To: <CAHk-=wgySgXXkZtx49Xq70X2CmSizM8siacYKncMmFWRzKjs5Q@mail.gmail.com>
On Mon, 5 Aug 2024 at 12:48, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> But x86 has the same context.vdso logic, and does *not* set the
> pointer before installing the vma, for example. Also does not zero it
> out on munmap(), although it does have the mremap logic.
Oh, and the empty stale arch_unmap() code on the x86 side has never
been about the vdso thing, it was about some horrid MPX notification
that no longer exists.
In case people wonder like I did.
Linus
^ permalink raw reply
* Re: [PATCH] syscalls: fix syscall macros for newfstat/newfstatat
From: Jakub Jelinek @ 2024-08-05 19:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rudi Heitbaum, Arnd Bergmann, Catalin Marinas, Will Deacon,
Huacai Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Andreas Schwab, Florian Weimer, linux-riscv, linux-arm-kernel,
linux-api, WANG Xuerui, Masami Hiramatsu, linux-kernel, loongarch
In-Reply-To: <c78916da-ee59-4ecb-9886-7bbc7f077fa5@app.fastmail.com>
On Sat, Aug 03, 2024 at 10:12:47AM +0200, Arnd Bergmann wrote:
> > Probably it would be useful to check
> > echo '#include <asm/unistd.h>' | gcc -E -dD -xc - | grep '#define __NR_' | sort
> > for all arches between 6.10 and the latest git, diff them and resolve any
> > unintended differences.
>
> Right, I should have done that before the original series really:
> I spent a lot of time validating the kernel's internal changes for
> consistency (which found a dozen bugs that were unrelated to my
> series) but missed the unintended changes to the external header
> contents.
>
> I'll do that now and send another fixup.
I've done 6.10 to 6.11-rc2 <asm/unistd.h> comparison just for the Fedora
arches (x86_64, aarch64, ppc64le, s390x, i686). Full details in
https://bugzilla.redhat.com/show_bug.cgi?id=2301919#c8
On i686, ppc64le and s390x there are no changes.
On x86_64
#define __NR_uretprobe 335
has been added, perhaps that is intentional, haven't checked.
On aarch64 when going just after __NR_ defined macros and their values,
I see:
#define __NR_nfsservctl 42
#define __NR_fstat 80
#define __NR_arch_specific_syscall 244
#define __NR_syscalls 463
removal and
#define __NR_newfstat 80
and addition and then
#define __NR3264_fcntl 25
#define __NR3264_statfs 43
#define __NR3264_fstatfs 44
#define __NR3264_truncate 45
#define __NR3264_ftruncate 46
#define __NR3264_lseek 62
#define __NR3264_sendfile 71
#define __NR3264_fstatat 79
#define __NR3264_fstat 80
#define __NR3264_mmap 222
#define __NR3264_fadvise64 223
macros are removed as well (let's hope it is an implementation detail and
nothing uses those macros, but some search would be helpful).
Jakub
^ permalink raw reply
* Re: [PATCH] syscalls: fix syscall macros for newfstat/newfstatat
From: Arnd Bergmann @ 2024-08-05 21:07 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Rudi Heitbaum, Arnd Bergmann, Catalin Marinas, Will Deacon,
Huacai Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Andreas Schwab, Florian Weimer, linux-riscv, linux-arm-kernel,
linux-api, WANG Xuerui, Masami Hiramatsu, linux-kernel, loongarch
In-Reply-To: <ZrEtyJd2qydKcWxQ@tucnak>
On Mon, Aug 5, 2024, at 21:53, Jakub Jelinek wrote:
> On Sat, Aug 03, 2024 at 10:12:47AM +0200, Arnd Bergmann wrote:
>> > Probably it would be useful to check
>> > echo '#include <asm/unistd.h>' | gcc -E -dD -xc - | grep '#define __NR_' | sort
>> > for all arches between 6.10 and the latest git, diff them and resolve any
>> > unintended differences.
>>
>> Right, I should have done that before the original series really:
>> I spent a lot of time validating the kernel's internal changes for
>> consistency (which found a dozen bugs that were unrelated to my
>> series) but missed the unintended changes to the external header
>> contents.
>>
>> I'll do that now and send another fixup.
>
> I've done 6.10 to 6.11-rc2 <asm/unistd.h> comparison just for the Fedora
> arches (x86_64, aarch64, ppc64le, s390x, i686). Full details in
> https://bugzilla.redhat.com/show_bug.cgi?id=2301919#c8
> On i686, ppc64le and s390x there are no changes.
> On x86_64
> #define __NR_uretprobe 335
This was a bit of a wild ride, but I think this number one should be
final, and only exist on x86-64.
> has been added, perhaps that is intentional, haven't checked.
> On aarch64 when going just after __NR_ defined macros and their values,
> I see:
> #define __NR_nfsservctl 42
> #define __NR_fstat 80
__NR_fstat was a very embarrassing bug that I introduced
while trying to fix __NR_newfstatat. I got confused by the
the way that the kernel internally uses newfstat() and
newfstatat() as the name, while the only macro name
for fstat() is missing the 'new'.
I also added a patch to add back __NR_nfsservctl to avoid
the unintended change, but this one is less clear since we
already dropped that macro on some architectures while
converting them to the new format but left the macro on
other architectures.
The syscall itself was removed in linux-3.2.
> #define __NR_arch_specific_syscall 244
> #define __NR_syscalls 463
> #define __NR3264_fcntl 25
> #define __NR3264_statfs 43
> #define __NR3264_fstatfs 44
> #define __NR3264_truncate 45
> #define __NR3264_ftruncate 46
> #define __NR3264_lseek 62
> #define __NR3264_sendfile 71
> #define __NR3264_fstatat 79
> #define __NR3264_fstat 80
> #define __NR3264_mmap 222
> #define __NR3264_fadvise64 223
> macros are removed as well (let's hope it is an implementation detail and
> nothing uses those macros, but some search would be helpful).
I did a Debian codesearch search for these and did not find
anything other than a couple of language bindings that copied
these from the kernel headers but nothing actually using them.
All of the above are implementation details that only
existed on arm64/riscv/loongarch/arc/openrisc/xtensa/nios2
because they were still using the old unistd.h format, and
they don't exist on any architecture that generates the
files from syscall.tbl.
Arnd
^ permalink raw reply
* Re: [PATCH RFT v7 0/9] fork: Support shadow stacks in clone3()
From: Shuah Khan @ 2024-08-05 21:29 UTC (permalink / raw)
To: Mark Brown, Rick P. Edgecombe, Deepak Gupta, Szabolcs Nagy,
H.J. Lu, Florian Weimer, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Mel Gorman, Daniel Bristot de Oliveira,
Valentin Schneider, Christian Brauner, Shuah Khan
Cc: linux-kernel, Catalin Marinas, Will Deacon, jannh,
linux-kselftest, linux-api, Kees Cook, David Hildenbrand,
Shuah Khan
In-Reply-To: <20240731-clone3-shadow-stack-v7-0-a9532eebfb1d@kernel.org>
On 7/31/24 06:14, Mark Brown wrote:
> The kernel has recently added support for shadow stacks, currently
> x86 only using their CET feature but both arm64 and RISC-V have
> equivalent features (GCS and Zicfiss respectively), I am actively
> working on GCS[1]. With shadow stacks the hardware maintains an
> additional stack containing only the return addresses for branch
> instructions which is not generally writeable by userspace and ensures
> that any returns are to the recorded addresses. This provides some
> protection against ROP attacks and making it easier to collect call
> stacks. These shadow stacks are allocated in the address space of the
> userspace process.
>
> Our API for shadow stacks does not currently offer userspace any
> flexiblity for managing the allocation of shadow stacks for newly
> created threads, instead the kernel allocates a new shadow stack with
> the same size as the normal stack whenever a thread is created with the
> feature enabled. The stacks allocated in this way are freed by the
> kernel when the thread exits or shadow stacks are disabled for the
> thread. This lack of flexibility and control isn't ideal, in the vast
> majority of cases the shadow stack will be over allocated and the
> implicit allocation and deallocation is not consistent with other
> interfaces. As far as I can tell the interface is done in this manner
> mainly because the shadow stack patches were in development since before
> clone3() was implemented.
>
> Since clone3() is readily extensible let's add support for specifying a
> shadow stack when creating a new thread or process in a similar manner
> to how the normal stack is specified, keeping the current implicit
> allocation behaviour if one is not specified either with clone3() or
> through the use of clone(). The user must provide a shadow stack
> address and size, this must point to memory mapped for use as a shadow
> stackby map_shadow_stack() with a shadow stack token at the top of the
> stack.
>
> Please note that the x86 portions of this code are build tested only, I
> don't appear to have a system that can run CET avaible to me, I have
> done testing with an integration into my pending work for GCS. There is
> some possibility that the arm64 implementation may require the use of
> clone3() and explicit userspace allocation of shadow stacks, this is
> still under discussion.
>
> Please further note that the token consumption done by clone3() is not
> currently implemented in an atomic fashion, Rick indicated that he would
> look into fixing this if people are OK with the implementation.
>
> A new architecture feature Kconfig option for shadow stacks is added as
> here, this was suggested as part of the review comments for the arm64
> GCS series and since we need to detect if shadow stacks are supported it
> seemed sensible to roll it in here.
>
> [1] https://lore.kernel.org/r/20231009-arm64-gcs-v6-0-78e55deaa4dd@kernel.org/
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> Changes in v7:
> - Rebase onto v6.11-rc1.
> - Typo fixes.
> - Link to v6: https://lore.kernel.org/r/20240623-clone3-shadow-stack-v6-0-9ee7783b1fb9@kernel.org
>
> Changes in v6:
> - Rebase onto v6.10-rc3.
> - Ensure we don't try to free the parent shadow stack in error paths of
> x86 arch code.
> - Spelling fixes in userspace API document.
> - Additional cleanups and improvements to the clone3() tests to support
> the shadow stack tests.
> - Link to v5: https://lore.kernel.org/r/20240203-clone3-shadow-stack-v5-0-322c69598e4b@kernel.org
>
> Changes in v5:
> - Rebase onto v6.8-rc2.
> - Rework ABI to have the user allocate the shadow stack memory with
> map_shadow_stack() and a token.
> - Force inlining of the x86 shadow stack enablement.
> - Move shadow stack enablement out into a shared header for reuse by
> other tests.
> - Link to v4: https://lore.kernel.org/r/20231128-clone3-shadow-stack-v4-0-8b28ffe4f676@kernel.org
>
> Changes in v4:
> - Formatting changes.
> - Use a define for minimum shadow stack size and move some basic
> validation to fork.c.
> - Link to v3: https://lore.kernel.org/r/20231120-clone3-shadow-stack-v3-0-a7b8ed3e2acc@kernel.org
>
> Changes in v3:
> - Rebase onto v6.7-rc2.
> - Remove stale shadow_stack in internal kargs.
> - If a shadow stack is specified unconditionally use it regardless of
> CLONE_ parameters.
> - Force enable shadow stacks in the selftest.
> - Update changelogs for RISC-V feature rename.
> - Link to v2: https://lore.kernel.org/r/20231114-clone3-shadow-stack-v2-0-b613f8681155@kernel.org
>
> Changes in v2:
> - Rebase onto v6.7-rc1.
> - Remove ability to provide preallocated shadow stack, just specify the
> desired size.
> - Link to v1: https://lore.kernel.org/r/20231023-clone3-shadow-stack-v1-0-d867d0b5d4d0@kernel.org
>
> ---
> Mark Brown (9):
> Documentation: userspace-api: Add shadow stack API documentation
> selftests: Provide helper header for shadow stack testing
> mm: Introduce ARCH_HAS_USER_SHADOW_STACK
> fork: Add shadow stack support to clone3()
> selftests/clone3: Remove redundant flushes of output streams
> selftests/clone3: Factor more of main loop into test_clone3()
> selftests/clone3: Explicitly handle child exits due to signals
> selftests/clone3: Allow tests to flag if -E2BIG is a valid error code
> selftests/clone3: Test shadow stack support
>
> Documentation/userspace-api/index.rst | 1 +
> Documentation/userspace-api/shadow_stack.rst | 41 ++++
> arch/x86/Kconfig | 1 +
> arch/x86/include/asm/shstk.h | 11 +-
> arch/x86/kernel/process.c | 2 +-
> arch/x86/kernel/shstk.c | 104 +++++++---
> fs/proc/task_mmu.c | 2 +-
> include/linux/mm.h | 2 +-
> include/linux/sched/task.h | 13 ++
> include/uapi/linux/sched.h | 13 +-
> kernel/fork.c | 76 ++++++--
> mm/Kconfig | 6 +
> tools/testing/selftests/clone3/clone3.c | 224 ++++++++++++++++++----
> tools/testing/selftests/clone3/clone3_selftests.h | 40 +++-
> tools/testing/selftests/ksft_shstk.h | 63 ++++++
> 15 files changed, 511 insertions(+), 88 deletions(-)
> ---
> base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
> change-id: 20231019-clone3-shadow-stack-15d40d2bf536
>
> Best regards,
For selftests:
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Nicholas Piggin @ 2024-08-05 23:24 UTC (permalink / raw)
To: Linus Torvalds, Jeff Xu
Cc: Michael Ellerman, Christophe Leroy, Pedro Falcato,
kernel test robot, Jeff Xu, oe-lkp, lkp, linux-kernel,
Andrew Morton, Kees Cook, Liam R. Howlett, Dave Hansen,
Greg Kroah-Hartman, Guenter Roeck, Jann Horn, Jonathan Corbet,
Jorge Lucangeli Obes, Matthew Wilcox, Muhammad Usama Anjum,
Stephen Röttger, Suren Baghdasaryan, Amer Al Shanawany,
Javier Carrasco, Shuah Khan, linux-api, linux-mm, ying.huang,
feng.tang, fengwei.yin
In-Reply-To: <CAHk-=wgySgXXkZtx49Xq70X2CmSizM8siacYKncMmFWRzKjs5Q@mail.gmail.com>
On Tue Aug 6, 2024 at 5:48 AM AEST, Linus Torvalds wrote:
> On Mon, 5 Aug 2024 at 12:38, Jeff Xu <jeffxu@google.com> wrote:
> >
> > I'm curious, why does ppc need to unmap vdso ? ( other archs don't
> > have unmap logic.)
>
> I have no idea. There are comments about 'perf' getting confused about
> mmap counts when 'context.vdso' isn't set up.
>
> But x86 has the same context.vdso logic, and does *not* set the
> pointer before installing the vma, for example. Also does not zero it
> out on munmap(), although it does have the mremap logic.
>
> For all I know it may all be entirely unnecessary, and could be
> removed entirely.
I don't know much about vdso code, it predated my involvedment in ppc.
Commit 83d3f0e90c6c8 says CRIU (checkpoint restore in userspace) is
moving it around. Why CRIU wants to do that, I don't know.
Can userspace on other archs not unmap their vdsos?
Thanks,
Nick
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Linus Torvalds @ 2024-08-06 0:13 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Jeff Xu, Michael Ellerman, Christophe Leroy, Pedro Falcato,
kernel test robot, Jeff Xu, oe-lkp, lkp, linux-kernel,
Andrew Morton, Kees Cook, Liam R. Howlett, Dave Hansen,
Greg Kroah-Hartman, Guenter Roeck, Jann Horn, Jonathan Corbet,
Jorge Lucangeli Obes, Matthew Wilcox, Muhammad Usama Anjum,
Stephen Röttger, Suren Baghdasaryan, Amer Al Shanawany,
Javier Carrasco, Shuah Khan, linux-api, linux-mm, ying.huang,
feng.tang, fengwei.yin
In-Reply-To: <D38D6LJZOIQK.2GV58PGVL5K85@gmail.com>
On Mon, 5 Aug 2024 at 16:25, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Can userspace on other archs not unmap their vdsos?
I think they can, and nobody cares. The "context.vdso" value stays at
some stale value, and anybody who tries to use it will just fail.
So what makes powerpc special is not "you can unmap the vdso", but
"powerpc cares".
I just don't quite know _why_ powerpc cares.
Judging by the comments and a quick 'grep', the reason may be
arch/powerpc/perf/callchain_32.c
which seems to have some vdso knowledge.
But x86 does something kind of like that at signal frame generation
time, and doesn't care.
I really think it's an issue of "if you screw with the vdso, you get
to keep both broken pieces".
Linus
^ permalink raw reply
* Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression
From: Jeff Xu @ 2024-08-06 1:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nicholas Piggin, Michael Ellerman, Christophe Leroy,
Pedro Falcato, kernel test robot, Jeff Xu, oe-lkp, lkp,
linux-kernel, Andrew Morton, Kees Cook, Liam R. Howlett,
Dave Hansen, Greg Kroah-Hartman, Guenter Roeck, Jann Horn,
Jonathan Corbet, Jorge Lucangeli Obes, Matthew Wilcox,
Muhammad Usama Anjum, Stephen Röttger, Suren Baghdasaryan,
Amer Al Shanawany, Javier Carrasco, Shuah Khan, linux-api,
linux-mm, ying.huang, feng.tang, fengwei.yin
In-Reply-To: <CAHk-=wjeWqr+0Ktzbwqrw17aESe5dZm5Kt6nwqtKJX00VsDqWg@mail.gmail.com>
On Mon, Aug 5, 2024 at 5:13 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, 5 Aug 2024 at 16:25, Nicholas Piggin <npiggin@gmail.com> wrote:
> >
> > Can userspace on other archs not unmap their vdsos?
>
> I think they can, and nobody cares. The "context.vdso" value stays at
> some stale value, and anybody who tries to use it will just fail.
>
I want to seal the vdso :-), so I also care (not having it changeable
from userspace)
For the restore scenario, if vdso is sealed, I guess CRIU won't be
able to relocate the vdso from userspace, I 'm interested in hearing
vdso dev's input on this , e.g. is that possible to make CRIU
compatible with memory sealing.
> So what makes powerpc special is not "you can unmap the vdso", but
> "powerpc cares".
>
> I just don't quite know _why_ powerpc cares.
>
> Judging by the comments and a quick 'grep', the reason may be
>
> arch/powerpc/perf/callchain_32.c
>
> which seems to have some vdso knowledge.
>
> But x86 does something kind of like that at signal frame generation
> time, and doesn't care.
>
> I really think it's an issue of "if you screw with the vdso, you get
> to keep both broken pieces".
>
> Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox