内存管理 – 调试内核模块(内存损坏_

发布时间：2020-12-14 01:14:34 所属栏目：Linux 来源：网络整理

导读：我正在调试我的内核模块,它似乎有内存损坏, 基本上是alloc_netdev()为’net_device’分配的一块内存实例已损坏. 1)我在我的内核的.config中启用了CONFIG_DEBUG_KERNEL,CONFIG_DEBUG_SLAB,CONFIG_DEBUG_KMEMLEAK,但是不确定kmemleak会发生什么.是否应该在读

我正在调试我的内核模块,它似乎有内存损坏,
基本上是alloc_netdev()为’net_device’分配的一块内存
实例已损坏.

1)我在我的内核的.config中启用了CONFIG_DEBUG_KERNEL,CONFIG_DEBUG_SLAB,CONFIG_DEBUG_KMEMLEAK,但是不确定kmemleak会发生什么.是否应该在读取/ sys / kernel / debug / kmemleak时打印出可疑内存泄漏的跟踪转储？有没有办法重置kmemleak积累的统计数据/信息？最重要的是 – 任何人都可以帮助解密输出,例如：

unreferenced object 0xc625e000 (size 2048):
  comm "swapper",pid 1,jiffies 4294937521
  backtrace:
    [<c00c89f0>] create_object+0x11c/0x200
    [<c00c6764>] __kmalloc_track_caller+0x138/0x178
    [<c01d78c0>] __alloc_skb+0x4c/0x100
    [<c01d8490>] dev_alloc_skb+0x18/0x3c
    [<c0198b48>] eth_rx_fill+0xd8/0x3fc
    [<c019ac74>] mv_eth_start_internals+0x30/0xf8
    [<c019c5fc>] mv_eth_start+0x70/0x244
    [<c019c810>] mv_eth_open+0x40/0x64
    [<c01e00f0>] dev_open+0xb4/0x118
    [<c01df788>] dev_change_flags+0x90/0x168
    [<c001a3e4>] ip_auto_config+0x1bc/0xecc
    [<c00212f4>] do_one_initcall+0x5c/0x1bc
    [<c00083d0>] kernel_init+0x8c/0x108
    [<c0022f58>] kernel_thread_exit+0x0/0x8
    [<ffffffff>] 0xffffffff

2)我也想知道我是否可以在这个内存上应用一些“只读”属性,这样我希望当有人试图修改内存时会产生Oops.听起来合理吗？

感谢任何建议,谢谢.

标记

解决方法

要捕获不正确的内存访问,KAsan或 kmemcheck可能更有用.但是,请注意,Kmemcheck会产生重大影响,有时可能是不可接受的,因此由您决定. KASan应该快得多.

1.
关于kmemleak,其操作在kernel docs中有详细描述.

简而言之,执行起来更可靠

echo scan > /sys/kernel/debug/kmemleak

作为root用户在读取/ sys / kernel / debug / kmemleak之前立即触发内存分析.有时,在阅读kmemleak的报告之前,我发现两次执行上述命令更加可靠.

要“重置”kmemleak收集的数据,您可以执行

echo clear /sys/kernel/debug/kmemleak

您发布的输出意味着kmemleak认为在工具上次分析内存时尚未释放地址为0xc625e000的2Kb内存区域.回溯指定内存的分配位置. “swapper”是已分配该内存区域的进程的名称.

2.
就设置存储器只读而言,这种技术确实用于内核的某些地方,例如保护内核的代码和模块.我不能在这里给出确切的说明,但set_page_attributes() function的实施是一个开始挖掘的好地方.

请注意,上面提到的kmemcheck使用了一种类似的技术来跟踪内存访问：使页面“看起来”就像它们不存在一样,因此每次访问它们都会导致页面错误等.详情请参阅kernel docs,与往常一样.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!