代码拉取完成，页面将自动刷新
After the memory is freed, it can be immediately allocated by other
CPUs, before the "free" trace report has been emitted. This causes
inaccurate traces.
For example, if the following sequence of events occurs:
CPU 0 CPU 1
(1) alloc xxxxxx
(2) free xxxxxx
(3) alloc xxxxxx
(4) free xxxxxx
Then they will be inaccurately reported via tracing, so that they appear
to have happened in this order:
CPU 0 CPU 1
(1) alloc xxxxxx
(2) alloc xxxxxx
(3) free xxxxxx
(4) free xxxxxx
This makes it look like CPU 1 somehow managed to allocate mmemory that
CPU 0 still had allocated for itself.
In order to avoid this, emit the "free xxxxxx" tracing report just
before the actual call to free the memory, instead of just after it.
mm/slab.c | 3 +--
mm/slob.c | 3 +--
mm/slub.c | 2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
Hi yeyunfeng-dev, welcome to the openEuler Community.
I'm the Bot here serving you. You can find the instructions on how to interact with me at Here.
If you have any questions, please contact the SIG: Kernel, and any of the maintainers: @成坚 (CHENG Jian) , @Qiuuuuu , @zhengzengkai , @gogooo , @Xie XiuQi , @YangYingliang
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
合入补丁验证情况：
[root@localhost ~]# uname -a
Linux localhost.localdomain 5.10.0+ #2 SMP Tue Dec 28 16:57:15 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
[root@localhost ~]#
[root@localhost ~]# cd /sys/kernel/debug/tracing/events/kmem/
[root@localhost kmem]# echo 1 > kmem_cache_free/enable
[root@localhost kmem]# echo 1 > kmem_cache_alloc/enable
[root@localhost kmem]# echo 1 > kmem_cache_alloc_node/enable
[root@localhost kmem]# cd ../../
[root@localhost tracing]# cat trace |tail -20
check_cron.sh-8593 [004] .... 390.083050: kmem_cache_free: call_site=security_file_free+0x58/0x68 ptr=00000000db6ea0c7
check_cron.sh-8593 [004] .... 390.083051: kmem_cache_free: call_site=security_file_free+0x58/0x68 ptr=000000005ae87d24
check_cron.sh-8593 [004] .... 390.083053: kmem_cache_free: call_site=security_file_free+0x58/0x68 ptr=000000006853fa83
check_cron.sh-8593 [004] .... 390.083056: kmem_cache_free: call_site=security_file_free+0x58/0x68 ptr=0000000022cfd8d4
check_cron.sh-8593 [004] .... 390.083057: kmem_cache_free: call_site=security_file_free+0x58/0x68 ptr=000000008f7c98bd
-0 [007] ..s. 390.099199: kmem_cache_alloc_node: call_site=__alloc_skb+0x68/0x1a8 ptr=0000000056078c64 bytes_req=224 bytes_alloc=256 gfp_flags=GFP_ATOMIC node=-1
-0 [003] ..s. 390.099200: kmem_cache_alloc_node: call_site=__alloc_skb+0x68/0x1a8 ptr=000000001dba08b4 bytes_req=224 bytes_alloc=256 gfp_flags=GFP_ATOMIC node=-1
-0 [003] ..s. 390.099223: kmem_cache_alloc: call_site=dst_alloc+0x68/0x1d0 ptr=00000000292277de bytes_req=192 bytes_alloc=192 gfp_flags=GFP_ATOMIC
-0 [007] ..s. 390.099223: kmem_cache_alloc: call_site=dst_alloc+0x68/0x1d0 ptr=00000000ab4ce046 bytes_req=192 bytes_alloc=192 gfp_flags=GFP_ATOMIC
-0 [007] ..s. 390.099232: kmem_cache_free: call_site=kfree_skbmem+0xc8/0xe8 ptr=0000000056078c64
-0 [003] ..s. 390.099233: kmem_cache_free: call_site=kfree_skbmem+0xc8/0xe8 ptr=000000001dba08b4
kmem_cache_alloc和kmem_cache_free trace轨迹功能正常
登录 后才可以发表评论
