为什么通过clear_refs可以使进程触发缺页?

平台

ARM64
Linux 6.10

作者

pengdonglin137@163.com

背景

最近在学习Linux的缺页异常时突然奇想,在不进行内存换出的情况下,如何让进程再次触发缺页?

基于对ARMv8的理解,它的MMU的页表项中有个AF位,当AF为0时,当访问到对应的虚拟页时,会触发缺页。

image

image

image

如果AF位为0,当访问到对应的虚拟页时,会触发MMU的Access flags fault。然后软件需要将这个AF位置1,之后再次访问时就不会触发这个异常了,而Linux中会使用下面的接口来清除和设置AF位:

// 清除
pmdp_test_and_clear_young
ptep_test_and_clear_young// 设置
pte_mkyoung

ptep_test_and_clear_young为例:

static inline int ptep_test_and_clear_young(struct vm_area_struct *vma,unsigned long address,pte_t *ptep)
{pte_t pte = ptep_get(ptep);int r = 1;if (!pte_young(pte))r = 0;elseset_pte_at(vma->vm_mm, address, ptep, pte_mkold(pte));return r;
}#define pte_young(pte)		(!!(pte_val(pte) & PTE_AF))static inline pte_t pte_mkold(pte_t pte)
{return clear_pte_bit(pte, __pgprot(PTE_AF));
}

这个接口用于清除PTE页表项的AF位,当再次访问时,会在缺页处理中设置AF位:

static vm_fault_t handle_pte_fault(struct vm_fault *vmf)
{pte_t entry;if (unlikely(pmd_none(*vmf->pmd))) {/** Leave __pte_alloc() until later: because vm_ops->fault may* want to allocate huge page, and if we expose page table* for an instant, it will be difficult to retract from* concurrent faults and from rmap lookups.*/vmf->pte = NULL;vmf->flags &= ~FAULT_FLAG_ORIG_PTE_VALID;} else {/** A regular pmd is established and it can't morph into a huge* pmd by anon khugepaged, since that takes mmap_lock in write* mode; but shmem or file collapse to THP could still morph* it into a huge pmd: just retry later if so.*/vmf->pte = pte_offset_map_nolock(vmf->vma->vm_mm, vmf->pmd,vmf->address, &vmf->ptl);if (unlikely(!vmf->pte))return 0;vmf->orig_pte = ptep_get_lockless(vmf->pte);vmf->flags |= FAULT_FLAG_ORIG_PTE_VALID;if (pte_none(vmf->orig_pte)) {pte_unmap(vmf->pte);vmf->pte = NULL;}}// 如果还没有映射物理页,其中在填充页表的时候会设置AF位,可以参考vm_get_page_protif (!vmf->pte)return do_pte_missing(vmf);// 如果已经被交换出去if (!pte_present(vmf->orig_pte))return do_swap_page(vmf);// 用于触发NUMA平衡,它会周期地把部分虚拟页对应PTE设置位PROT_NONE,读和写都会触发异常if (pte_protnone(vmf->orig_pte) && vma_is_accessible(vmf->vma))return do_numa_page(vmf);spin_lock(vmf->ptl);entry = vmf->orig_pte;// 通过其他路径已经设置了页表项if (unlikely(!pte_same(ptep_get(vmf->pte), entry))) {update_mmu_tlb(vmf->vma, vmf->address, vmf->pte);goto unlock;}if (vmf->flags & (FAULT_FLAG_WRITE|FAULT_FLAG_UNSHARE)) {if (!pte_write(entry)) // 写时复制return do_wp_page(vmf);else if (likely(vmf->flags & FAULT_FLAG_WRITE))entry = pte_mkdirty(entry);}// 对于AF位触发的缺页,上面地条件不会满足,会走这里,设置AF位entry = pte_mkyoung(entry);if (ptep_set_access_flags(vmf->vma, vmf->address, vmf->pte, entry,vmf->flags & FAULT_FLAG_WRITE)) {update_mmu_cache_range(vmf, vmf->vma, vmf->address,vmf->pte, 1);} else {/* Skip spurious TLB flush for retried page fault */if (vmf->flags & FAULT_FLAG_TRIED)goto unlock;/** This is needed only for protection faults but the arch code* is not yet telling us if this is a protection fault or not.* This still avoids useless tlb flushes for .text page faults* with threads.*/if (vmf->flags & FAULT_FLAG_WRITE)flush_tlb_fix_spurious_fault(vmf->vma, vmf->address,vmf->pte);}
unlock:pte_unmap_unlock(vmf->pte, vmf->ptl);return 0;
}

而clear_refs地实现就利用了这一点,这里是关于这个节点的用法:/proc/pid/clear_refs

# 清除进程所有虚拟区域的 Access/PG_reference
# DEFINE: CLEAR_REFS_ALL 1
echo 1 > /proc/PID/clear_refs# 清除进程所有匿名映射区域的 Access/PG_reference
# DEFINE: CLEAR_REFS_ANON 2
echo 2 > /proc/PID/clear_refs# 清除进程所有文件映射区域的 Access/PG_reference
# DEFINE: CLEAR_REFS_MAPPED 3
echo 3 > /proc/PID/clear_refs# 清除进程所有软脏页标志
# DEFINE: CLEAR_REFS_SOFT_DIRTY 4
echo 4 > /proc/PID/clear_refs# 重置进程的 Hiwater_rss
# DEFINE: CLEAR_REFS_MM_HIWATER_RSS 5
echo 5 > /proc/PID/clear_refs

实现

当向clear_refs写入数值时,函数clear_refs_write被回调,这个函数中会调用:

walk_page_range(mm, 0, -1, &clear_refs_walk_ops, &cp);

其中walk_page_range负责遍历页表,在遍历的过程中会回调clear_refs_walk_ops中的函数:

static const struct mm_walk_ops clear_refs_walk_ops = {.pmd_entry		= clear_refs_pte_range,.test_walk		= clear_refs_test_walk,.walk_lock		= PGWALK_WRLOCK,
};
  • test_walk回调:用于判断是否跳过当前vma,返回0表示需要遍历当前vma,返回-1表示结束遍历,返回1表示跳过当前vma
  • pmd_entry回调:处理一个非空的PMD entry

先看一下如何判断是否遍历当前vma的实现:

static int clear_refs_test_walk(unsigned long start, unsigned long end,struct mm_walk *walk)
{struct clear_refs_private *cp = walk->private;struct vm_area_struct *vma = walk->vma;// 不是通过struct page来映射的if (vma->vm_flags & VM_PFNMAP)return 1;/** Writing 1 to /proc/pid/clear_refs affects all pages.* Writing 2 to /proc/pid/clear_refs only affects anonymous pages.* Writing 3 to /proc/pid/clear_refs only affects file mapped pages.* Writing 4 to /proc/pid/clear_refs affects all pages.*/// 如果要清除的是匿名页,但是当前vma映射到的是文件,那么跳过当前vmaif (cp->type == CLEAR_REFS_ANON && vma->vm_file)return 1;// 如果要清除的是文件页,但是当前vma是匿名的,那么跳过当前vmaif (cp->type == CLEAR_REFS_MAPPED && !vma->vm_file)return 1;// 处理当前vmareturn 0;
}

接下来看看如何清除页表项的AF位:

static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr,unsigned long end, struct mm_walk *walk)
{struct clear_refs_private *cp = walk->private;struct vm_area_struct *vma = walk->vma;pte_t *pte, ptent;spinlock_t *ptl;struct folio *folio;ptl = pmd_trans_huge_lock(pmd, vma);if (ptl) {  // 如果是PMD映射的巨型页if (cp->type == CLEAR_REFS_SOFT_DIRTY) {clear_soft_dirty_pmd(vma, addr, pmd);goto out;}if (!pmd_present(*pmd))  // 如果被swap出去了,跳过goto out;folio = pmd_folio(*pmd);/* Clear accessed and referenced bits. */pmdp_test_and_clear_young(vma, addr, pmd);  // 清除PMD页表项的AF位folio_test_clear_young(folio);folio_clear_referenced(folio);
out:spin_unlock(ptl);return 0;}pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);if (!pte) {walk->action = ACTION_AGAIN;return 0;}for (; addr != end; pte++, addr += PAGE_SIZE) {ptent = ptep_get(pte);if (cp->type == CLEAR_REFS_SOFT_DIRTY) {clear_soft_dirty(vma, addr, pte);continue;}if (!pte_present(ptent))  // 如果被swap出去了,跳过continue;folio = vm_normal_folio(vma, addr, ptent);if (!folio)continue;/* Clear accessed and referenced bits. */ptep_test_and_clear_young(vma, addr, pte);  // 清除PTE页表项的AF位folio_test_clear_young(folio);folio_clear_referenced(folio);}pte_unmap_unlock(pte - 1, ptl);cond_resched();return 0;
}

实验

下面通过实验来观察和学习:

思路是:

  • 进程通过malloc申请一块匿名内存,然后通过memset或者mlock等接口事先分配好物理页。接着反复去访问这段内存
  • 通过向clear_refs写入2来清除匿名页的AF位
  • 通过各种工具来观察缺页

测试程序

leak2.c

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/mman.h>char *addr;// 16MB
int size = 0x1000*0x1000;int func3(void)
{static int i = 0;char *access;int ret = 0;printf("%s enter.\n", __func__);access = addr + 0x1000*i;printf("p: %d, s: %p, e: %p, %s access addr: %p\n",getpid(), addr, addr + size,i&0x1 ? "write" : "read",access);if (i & 0x1)*access = 0x5a;  // 触发写访问缺页elseret = *access;   // 触发读访问缺页sleep(1);i++;if (i >= 0x1000)i = 0;return ret;
}int func2(void)
{printf("%s enter.\n", __func__);return func3();
}int  func1(void)
{printf("%s enter.\n", __func__);return func2();
}int main(void)
{int ret;printf("%s enter.\n", __func__);addr = malloc(size);if (!addr) {printf("alloc buf failed\n");return -1;}/*为了测试方便,使更容易观察到缺页,不使用THP,即不使用透明巨型页映射。需要注意的是,不能把将THP的策略配置为always,否则总是会按照2MB的巨型页去映射root@arm64:/sys/kernel/mm/transparent_hugepage# cat enabledalways [madvise] never*/ret = madvise((void *)((unsigned long)addr & ~(0x1000 - 1)), size, MADV_NOHUGEPAGE);if (ret < 0) {perror("set nohugepage failed");return -1;}// 这个区域如果发生缺页的话,一次只映射一个page,由于下面用了mlockall,这步可以不做ret = madvise((void *)((unsigned long)addr & ~(0x1000 - 1)), size, MADV_RANDOM);if (ret < 0) {perror("set random failed\n");return -1;}// 预先给这片区域映射物理页// memset(addr, 0, size);if (mlockall(MCL_CURRENT | MCL_FUTURE) < 0) {perror("mlockall failed");return -1;}while (1)func1();return 0;
}

开始运行后,可以看到如下日志:

func1 enter.
func2 enter.
func3 enter.
p: 2058, s: 0xffff9a600010, e: 0xffff9b600010,  write access addr: 0xffff9a611010
func1 enter.
func2 enter.
func3 enter.
p: 2058, s: 0xffff9a600010, e: 0xffff9b600010,   read access addr: 0xffff9a612010

查看映射

root@arm64:/sys/kernel/mm/transparent_hugepage# pmap -x `pidof leak2`
2058:   ./leak2
Address           Kbytes     RSS   Dirty Mode  Mapping
0000aaaab9690000       4       4       0 r-x-- leak2
0000aaaab96a1000       4       4       4 r---- leak2
0000aaaab96a2000       4       4       4 rw--- leak2
0000aaaae9238000     132     132     132 rw---   [ anon ]
> 0000ffff9a600000   16384   16384   16384 rw---   [ anon ]
0000ffff9b600000       4       4       4 rw---   [ anon ]
0000ffff9b796000    1388    1388       0 r-x-- libc-2.31.so
0000ffff9b8f1000      60       0       0 ----- libc-2.31.so
0000ffff9b900000      16      16      16 r---- libc-2.31.so
0000ffff9b904000       8       8       8 rw--- libc-2.31.so
0000ffff9b906000      12      12      12 rw---   [ anon ]
0000ffff9b909000     132     132       0 r-x-- ld-2.31.so
0000ffff9b92b000       8       8       8 rw---   [ anon ]
0000ffff9b937000       8       0       0 r----   [ anon ]
0000ffff9b939000       4       4       0 r-x--   [ anon ]
0000ffff9b93a000       4       4       4 r---- ld-2.31.so
0000ffff9b93b000       8       8       8 rw--- ld-2.31.so
0000ffffd0312000     132     132     132 rw---   [ stack ]
---------------- ------- ------- -------
total kB           18312   18244   16716

使用crash的vtop命令确认一下是否为按4KB的物理页映射的:

crash> vtop ffff9a600000
VIRTUAL     PHYSICAL
ffff9a600000  138ae7000PAGE DIRECTORY: ffff0000d719b000PGD: ffff0000d719bff8 => 800000116e70003PUD: ffff0000d6e70ff0 => 800000116f6d003PMD: ffff0000d6f6d698 => 800000116b4d003PTE: ffff0000d6b4d000 => e8000138ae7f43PAGE: 138ae7000PTE        PHYSICAL   FLAGS
e8000138ae7f43  138ae7000  (VALID|USER|SHARED|AF|NG|PXN|UXN|DIRTY)VMA           START       END     FLAGS FILE
ffff0000d739d768 ffff9a600000 ffff9b600000 40112073PAGE        PHYSICAL      MAPPING       INDEX CNT FLAGS
fffffdffc3e2b9c0 138ae7000 ffff0000cc765cc9 ffff9a600  1 bfffe00001d0028 uptodate,lru,mappedtodisk,swapbacked,unevictable,mlocked

上面PTE这行就是虚拟地址ffff9a600000对用的PTE页表项的内容的解析。

上面指示的区域就是malloc申请的16MB的匿名页内存区域,RSS大小也是16MB,意味着这块虚拟内存已经全部映射到了物理页。

缺页次数

top - 14:59:55 up 28 min,  4 users,  load average: 0.08, 0.33, 0.50
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  2.3 sy,  0.0 ni, 97.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   3658.2 total,   2607.2 free,    612.3 used,    438.7 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   2904.3 avail MemnMaj nMin     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND0 4271    2058 pengdl    20   0   18312  18100   1460 S   0.0   0.5   0:01.67 leak2

通过top命令统计leak2进程的发生的缺页次数,主要是nMin(次缺页)。

正常情况下,nMin是恒定的,当执行下面的命令后:

echo 2 > /proc/`pidof leak2`/clear_refs

然后可以看到nMin会每秒增加1。用pidstat也可以佐证:

root@arm64:~# pidstat -r 1 -p `pidof leak2`
Linux 6.10.0+ (arm64)   08/23/24        _aarch64_       (4 CPU)15:16:33      UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
15:16:34     1000      2058      0.99      0.00   18312   18100   0.48  leak2
15:16:35     1000      2058      1.00      0.00   18312   18100   0.48  leak2
15:16:36     1000      2058      1.00      0.00   18312   18100   0.48  leak2
15:16:37     1000      2058      0.99      0.00   18312   18100   0.48  leak2
15:16:38     1000      2058      1.00      0.00   18312   18100   0.48  leak2
15:16:39     1000      2058      1.00      0.00   18312   18100   0.48  leak2
15:16:40     1000      2058      1.00      0.00   18312   18100   0.48  leak2

内核是如何统计nMaj和nMin的呢?可以参考mm_account_fault。nMaj表示在处理缺页的时候需要从后备存储(如文件、swap设备、块设备等)读取数据到page,然后进行映射。而nMin表示数据已经在内存里了,只需要修改一下页表映射,相比之下nMin的开销要比nMaj小很多。

使用perf观察缺页,并且记录调用栈

perf支持缺页事件:

# perf list
...major-faults                                       [Software event]minor-faults                                       [Software event]page-faults OR faults                              [Software event]
...

可以参考内核代码,其实上面两个事件也是在mm_account_fault中进行记录的:

/*** mm_account_fault - Do page fault accounting* @mm: mm from which memcg should be extracted. It can be NULL.* @regs: the pt_regs struct pointer.  When set to NULL, will skip accounting*        of perf event counters, but we'll still do the per-task accounting to*        the task who triggered this page fault.* @address: the faulted address.* @flags: the fault flags.* @ret: the fault retcode.** This will take care of most of the page fault accounting.  Meanwhile, it* will also include the PERF_COUNT_SW_PAGE_FAULTS_[MAJ|MIN] perf counter* updates.  However, note that the handling of PERF_COUNT_SW_PAGE_FAULTS should* still be in per-arch page fault handlers at the entry of page fault.*/
static inline void mm_account_fault(struct mm_struct *mm, struct pt_regs *regs,unsigned long address, unsigned int flags,vm_fault_t ret)
{bool major;/* Incomplete faults will be accounted upon completion. */if (ret & VM_FAULT_RETRY)return;/** To preserve the behavior of older kernels, PGFAULT counters record* both successful and failed faults, as opposed to perf counters,* which ignore failed cases.*/count_vm_event(PGFAULT);count_memcg_event_mm(mm, PGFAULT);/** Do not account for unsuccessful faults (e.g. when the address wasn't* valid).  That includes arch_vma_access_permitted() failing before* reaching here. So this is not a "this many hardware page faults"* counter.  We should use the hw profiling for that.*/if (ret & VM_FAULT_ERROR)return;/** We define the fault as a major fault when the final successful fault* is VM_FAULT_MAJOR, or if it retried (which implies that we couldn't* handle it immediately previously).*/major = (ret & VM_FAULT_MAJOR) || (flags & FAULT_FLAG_TRIED);if (major)current->maj_flt++;elsecurrent->min_flt++;/** If the fault is done for GUP, regs will be NULL.  We only do the* accounting for the per thread fault counters who triggered the* fault, and we skip the perf event updates.*/if (!regs)return;if (major)perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1, regs, address);elseperf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1, regs, address);
}

执行如下命令:

# perf record -e minor-faults -g -p `pidof leak2`
# perf script
root@arm64:~# perf script
leak2    2058  4140.293988:          1 minor-faults:aaaab9690a60 func3+0xe4 (/home/pengdl/demo/kmemleak/leak2)aaaab9690ae4 func2+0x20 (/home/pengdl/demo/kmemleak/leak2)aaaab9690b0c func1+0x20 (/home/pengdl/demo/kmemleak/leak2)aaaab9690c54 main+0x140 (/home/pengdl/demo/kmemleak/leak2)ffff9b7b6e10 __libc_start_main+0xe8 (/usr/lib/aarch64-linux-gnu/libc-2.31.so)aaaab96908a4 _start+0x34 (/home/pengdl/demo/kmemleak/leak2)leak2    2058  4141.307048:          1 minor-faults:aaaab9690a6c func3+0xf0 (/home/pengdl/demo/kmemleak/leak2)aaaab9690ae4 func2+0x20 (/home/pengdl/demo/kmemleak/leak2)aaaab9690b0c func1+0x20 (/home/pengdl/demo/kmemleak/leak2)aaaab9690c54 main+0x140 (/home/pengdl/demo/kmemleak/leak2)ffff9b7b6e10 __libc_start_main+0xe8 (/usr/lib/aarch64-linux-gnu/libc-2.31.so)aaaab96908a4 _start+0x34 (/home/pengdl/demo/kmemleak/leak2)
...

使用mem_abort事件

trace_event

内核导出了下面的trace point:

root@arm64:/sys/kernel/debug/tracing/events/exceptions# ls -l
total 0
-rw-r----- 1 root root 0 Aug 23 15:43 enable
-rw-r----- 1 root root 0 Aug 23 15:43 filter
drwxr-xr-x 1 root root 0 Aug 23 15:36 mem_abort_kernel
drwxr-xr-x 1 root root 0 Aug 23 15:36 mem_abort_user

从名字可以看到,当进程在用户态触发了mem abort,那么会触发mem_abort_user事件:

root@arm64:/sys/kernel/debug/tracing/events/exceptions/mem_abort_user# cat format
name: mem_abort_user
ID: 32
format:field:unsigned short common_type;       offset:0;       size:2; signed:0;field:unsigned char common_flags;       offset:2;       size:1; signed:0;field:unsigned char common_preempt_count;       offset:3;       size:1; signed:0;field:int common_pid;   offset:4;       size:4; signed:1;field:unsigned long address;    offset:8;       size:8; signed:0;field:unsigned long ip; offset:16;      size:8; signed:0;field:unsigned long error_code; offset:24;      size:8; signed:0;print fmt: "address=%ps ip=%ps error_code=0x%lx", (void *)REC->address, (void *)REC->ip, REC->error_code

可以使用这个事件进行测试:

# cd /sys/kernel/debug/tracing/events/exceptions/mem_abort_user
# echo 'comm ~ "leak2"' > filter
# echo 1 > enable
# echo 1 > /sys/kernel/tracing/tracing_on

可以看到如下日志:

root@arm64:/sys/kernel/debug/tracing/events/exceptions/mem_abort_user# cat /sys/kernel/tracing/trace_pipeleak2-2058    [001] .....  5312.321453: mem_abort_user: address=0xffff9a71e010 ip=0xaaaab9690a6c error_code=0x9200000bleak2-2058    [001] .....  5313.327391: mem_abort_user: address=0xffff9a71f010 ip=0xaaaab9690a60 error_code=0x9200004bleak2-2058    [001] .....  5314.331440: mem_abort_user: address=0xffff9a720010 ip=0xaaaab9690a6c error_code=0x9200000bleak2-2058    [001] .....  5315.337957: mem_abort_user: address=0xffff9a721010 ip=0xaaaab9690a60 error_code=0x9200004b

此外,也可以对trace event进行配置,当记录事件的时候把内核栈和用户栈也一并记录下来:

# cd /sys/kernel/debug/tracing/options
# echo 1 > userstacktrace
# echo 1 > stacktrace
# echo 1 > sym-userobj

此时看到的日志如下:

           leak2-2058    [001] .....  5537.394169: mem_abort_user: address=0xffff9a7fe010 ip=0xaaaab9690a6c error_code=0x9200000bleak2-2058    [001] .....  5537.394650: <stack trace>=> do_mem_abort=> el0_da=> el0t_64_sync_handler=> el0t_64_syncleak2-2058    [001] .....  5537.394672: <user stack trace>=> /home/pengdl/demo/kmemleak/leak2[+0xa6c]=> /home/pengdl/demo/kmemleak/leak2[+0xae4]=> /home/pengdl/demo/kmemleak/leak2[+0xb0c]=> /home/pengdl/demo/kmemleak/leak2[+0xc54]=> /usr/lib/aarch64-linux-gnu/libc-2.31.so[+0x20e10]=> /home/pengdl/demo/kmemleak/leak2[+0x8a4]leak2-2058    [001] .....  5538.399253: mem_abort_user: address=0xffff9a7ff010 ip=0xaaaab9690a60 error_code=0x9200004bleak2-2058    [001] .....  5538.401479: <stack trace>=> do_mem_abort=> el0_da=> el0t_64_sync_handler=> el0t_64_syncleak2-2058    [001] .....  5538.401545: <user stack trace>=> /home/pengdl/demo/kmemleak/leak2[+0xa60]=> /home/pengdl/demo/kmemleak/leak2[+0xae4]=> /home/pengdl/demo/kmemleak/leak2[+0xb0c]=> /home/pengdl/demo/kmemleak/leak2[+0xc54]=> /usr/lib/aarch64-linux-gnu/libc-2.31.so[+0x20e10]=> /home/pengdl/demo/kmemleak/leak2[+0x8a4]

使用perf

内核导出了mem_abort事件:

root@arm64:~# perf list | grep mem_abortexceptions:mem_abort_kernel                        [Tracepoint event]exceptions:mem_abort_user                          [Tracepoint event]

然后使用下面的命令记录:

# perf record -e exceptions:mem_abort_user -g -p `pidof leak2`

解析抓到的数据:

root@arm64:~# perf script
leak2    2058 [000]  4855.336563: exceptions:mem_abort_user: address=0xffff9b557010 ip=0xaaaab9690a60 error_code=0x9200004bffff80008002aae0 do_mem_abort+0xc8 ([kernel.kallsyms])ffff80008002aae0 do_mem_abort+0xc8 ([kernel.kallsyms])ffff800080c73380 el0_da+0x38 ([kernel.kallsyms])ffff800080c74504 el0t_64_sync_handler+0xe4 ([kernel.kallsyms])ffff80008001150c el0t_64_sync+0x14c ([kernel.kallsyms])aaaab9690a60 func3+0xe4 (/home/pengdl/demo/kmemleak/leak2)aaaab9690ae4 func2+0x20 (/home/pengdl/demo/kmemleak/leak2)aaaab9690b0c func1+0x20 (/home/pengdl/demo/kmemleak/leak2)aaaab9690c54 main+0x140 (/home/pengdl/demo/kmemleak/leak2)ffff9b7b6e10 __libc_start_main+0xe8 (/usr/lib/aarch64-linux-gnu/libc-2.31.so)aaaab96908a4 _start+0x34 (/home/pengdl/demo/kmemleak/leak2)

此外,因为是基于trace point,所以还可以对数据进行筛选和过滤,比如:

root@arm64:~# perf record -e exceptions:mem_abort_user -g --filter 'address <= 0xffff9b600010 && address >= 0xffff9a600010 && common_pid == 2058 && comm ~ "leak2"'

完。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/786134.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

复选框单选

const lastDataHandle = ref(null); // 上次选择的dataHandle值 const dataHandle: any = ref([]); const dataHandleALLList = [{ label: 无, value: 0 },{ label: 上传照片, value: 1 },{ label: 二维建模, value: 2 }, ]; // 单选 function setLastDataHandle() {lastDataHa…

解码“智慧市政”的创新实践与战略意义

在这个日新月异的信息时代,智慧城市建设已成为全球共识,而“智慧市政”作为其核心组成部分,正以前所未有的速度重塑城市管理和服务模式。智慧市政:定义与价值智慧市政,是指利用先进的信息技术,如地理信息系统(GIS)、物联网(IoT)、大数据分析、人工智能(AI)等,对城…

WPF 模仿前端大佬写一个Hover效果

先看一下效果吧: 原博主的地址:【动画进阶】神奇的卡片 Hover 效果与 Blur 的特性探究 - ChokCoco - 博客园 (cnblogs.com) 原效果是一个css效果,我们采用WPF的方式模仿一下 因为技术有限,没有原博主的那么好看,毕竟盗版永远比不过原版... 然后这里看一下盗版的怎么写吧 先…

信息收集利器|一款功能强大的子域收集工具

01工具介绍 (下载地址见最后) 在hw等攻防演练中,信息收集做为演练厨师阶段最重要的步骤,方式方法尤为重要,好的工具达到事半功倍的效果。OneForAll是一款集百家之长,功能强大的全面快速子域收集终极神器。 解决以下痛点: 在渗透测试中信息收集的重要性不言而喻,子域收集…

[poc] hw情报-泛微 e-cology v10 远程代码执行漏洞

漏洞介绍 (poc下载地址见最后)泛微披露了e-cology远程代码执行漏洞。该漏洞允许攻击者通过e-cology-10.0前台获取管理员访问令牌,然后利用JDBC反序列化,实现远程代码执行。 漏洞描述通过/papi/passport/rest/appThirdLogin接口获取管理员账号票据,根据该票据获取访问令牌,…

Tita的OKR :产品经理的OKR

产品经理制定的OKR,对组织发展有重大的意义,它能促使产品经理,产品团队,乃至是公司全体员工走出舒适区,超越能力边界。正因为挑战的存在,才使得产品经理才有忧患意识,不断改进产品,从而适应竞争激烈的市场。只有不断改善、创新和突破,才能让产品经理的能力不断提升,才…

About Living 生存之道

About Living 生存之道 爱 健康 财富 是人生值得追求的东西!人生不过是一段体验。我们都是时间的囚徒,活在当下。有趣!有料! 一个人的命运啊,当然要靠自我奋斗,但是也要考虑到历史的行程---奋斗是加法,趋势是乘法 我相信这世界上,有些人有些事有些爱,在见到的第一次,…

JAVA 封装

封装 1.“高内聚,低耦合” 2.属性私有 alt+insert创建get/set方法,方法内部可以进行判断参数是否合法 意义:1.提高程序的安全性,保护数据 2.隐藏代码的实现细节 3.统一接口(get/set方法) 4..增加系统的可维护性 成员变量的隐藏 “就近原则”,子类新定义的方法可以…

怎么都在劝我用通义灵码

听朋友说最近通义灵码有个活动,分享体验心得就有机会抽 iPhone 15。而且通过活动第一次使用通义灵码的新用户,还人均送一个“显眼包”。听朋友说最近通义灵码有个活动,分享体验心得就有机会抽 iPhone 15。而且通过活动第一次使用通义灵码的新用户,还人均送一个“显眼包”。…

卡特兰数、Prufer 序列、BSGS 总结

卡特兰数 定义 给定 \(n\) 个 \(0\) 和 \(n\) 个 \(1\),它们构成一个长度为 \(2n\) 的排列,满足任意前缀中 \(0\) 的个数都不少于 \(1\) 的个数的序列的数量为卡特兰数列。显然 \(H_0=H_1=1\)。(\(H\) 为卡特兰数列) 通项公式: \[H_n=\frac{\dbinom{2n}{n}}{n+1}\quad (n\…

[Flink] Flink CDC Connactors FAQ

Flink CDC Connactors FAQ 近期遇到 Flink CDC 的问题较多,故基于第1篇参考文献的FAQ文档基础之上,对这些问题做个系统的总结。 MYSQL CDC Q:作业报错 ConnectException: A slave with the same server_uuid/server_id as this slave has connected to the master,怎么办呢?…

少儿编程概述

少儿编程少儿编程 技术参考少儿编程的核心理念是培养孩子思维模式,解决问题逻辑等综合能力,与传统意义上的编程有很大区别。前者培养能力,后者专注技术。国外少儿编程较国内更早开始发展,主要代表有开源平台Scratch以及拥有成熟体系的Tynker。Scratch语言 与 编程猫的Kitte…