This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] Linux:AM57x 内核中的内存泄漏

Guru**** 2589280 points
Other Parts Discussed in Thread: AM5728

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/637760/linux-memory-leaks-in-am57x-kernel

主题中讨论的其他器件:AM5728

工具/软件:Linux

我使用的是 TI AM57xx Sitara 板。 但运行 kmemleak 后、 内核中出现以下内存泄漏。 Linux 内核版本为4.9.28,TI SDK 为 ti-processor-sdk-linux-am57xx-evm-04.00.00.04。  泄漏的原因是什么?如何清除它们?

root@am57xx-EVM:~# cat /sys/kernel/debug/kmemleak
未引用对象0xedc16e00 (大小64):
Comm "swapper/0"、pid 1、jiffies 4294937364 (age 455.870s)
十六进制转储(前32个字节):
44 18 05 C1 00 00 00 01 00 00 01 00 00 00 D…………………………………………………………………
00 00 00 00 44 18 05 C1 cc D3 01 C1 cc D3 01 C1...D.
回溯:
[ ]__kmalloc+0x194/0x210
[ ]__register_sysctl_table+0x58/0x630
[ ] register_sysctl+0x20/0x24
[ ] USER_namespace_sysctl_init+0x1c/0x48
[ ] do_one _initcall+0x4c/0x178
[ ] kernel_init_freeed+0x1d8/0x268
[ ] kernel_init+0x10/0x110
[ ] RET_FANK_+0x14/0x2C
[ ] 0xffffffff
未引用对象0xd5650000 (大小1024):
Comm "kwork/0:0"、pid 4、jiffies 4294938272 (age 446.860s)
十六进制转储(前32个字节):
01 00 00 52 01 00 52 01 00 52 00 52 01 00 52 00 52 ... R..R..R..R
01 00 00 52 01 00 52 01 00 00 52 01 00 52 01 00 52 ... R..R..R..R
回溯:
[ ] kmem_cache_alloc+0x174/0x1d8
[ ] iointe_alloc+0x5c/0xc8
[ ] iopte_alloc_large+0x34/b4
[ ] omap_iommu_map+0x1a0/0x1f8
[ ] iommu_map+0x10c/0x180
[ ] rproc_handle_devmem+0x7c/0x12c [remoteproc]
[ ] rproc_handle_resources+0x64/0xe8 [remoteproc]
[ ]__rproc_boot+0x1c4/0x5bc [remoteproc]
[ ] rproc_auto_boot_callback+0x18/0x24 [remoteproc]
[ ] REQUEST_firmware_work _func+0x44/0x6c
[ ] Process_One_Work+0x1dc/0x3f8
[ ] Worker_thread+0x58/0x574
[ ] kthread+0x100/0x118
[ ] RET_FANK_+0x14/0x2C
[ ] 0xffffffff
未引用对象0xd5650800 (大小1024):
Comm "kworker/0:0"、pid 4、jiffies 4294938272 (age 446.860s)
十六进制转储(前32个字节):
01 00 00 52 01 00 52 01 00 52 00 52 01 00 52 00 52 ... R..R..R..R
01 00 00 52 01 00 52 01 00 00 52 01 00 52 01 00 52 ... R..R..R..R
回溯:
[ ] kmem_cache_alloc+0x174/0x1d8
[ ] iointe_alloc+0x5c/0xc8
[ ] iopte_alloc_large+0x34/b4
[ ] omap_iommu_map+0x1a0/0x1f8
[ ] iommu_map+0x10c/0x180
[ ] rproc_handle_devmem+0x7c/0x12c [remoteproc]
[ ] rproc_handle_resources+0x64/0xe8 [remoteproc]
[ ]__rproc_boot+0x1c4/0x5bc [remoteproc]
[ ] rproc_auto_boot_callback+0x18/0x24 [remoteproc]
[ ] REQUEST_firmware_work _func+0x44/0x6c
[ ] Process_One_Work+0x1dc/0x3f8
[ ] Worker_thread+0x58/0x574
[ ] kthread+0x100/0x118
[ ] RET_FANK_+0x14/0x2C
[ ] 0xffffffff
未引用对象0xd5651000 (大小1024):
Comm "kwork/0:0"、pid 4、jiffies 4294938272 (age 446.860s)
十六进制转储(前32个字节):
01 00 30 40 01 00 30 40 01 00 30 40 01 00 30 40 .0@..0@..0@..0@..0……
01 00 30 40 01 00 30 40 01 00 30 40 01 00 30 40@.0@..0@..0@..0
回溯:
[ ] kmem_cache_alloc+0x174/0x1d8
[ ] iointe_alloc+0x5c/0xc8
[ ] iopte_alloc_large+0x34/b4 

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    软件团队已收到通知。 他们将在这里作出回应。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您是否还可以指定所做的内核配置更改?
    是否仅启用了"内核内存泄漏检测器"更改(CONFIG_DEBUG_KMEMLEAK = Y)?

    BR
    Tsvetolin Shulev

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好,Tsvetolin Shulev,

    感谢您的回答。

    我正在共享内核配置文件。

    e2e.ti.com/.../7282.config.txt

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Vikash、

    我在上一个 Processor SDK 版本04.01.00.06中重现了此问题。 此问题需要进一步调查。

    BR
    Tsvetolin Shulev
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Tsvetolin Shulev 是否有关于此问题的任何更新?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Vikash、

    我也在 AM5728 IDK 上复制了结果。 进一步深入探究、泄漏似乎与 Remoteproc 及其所使用的处理器间通信(例如、在 ARM 和 DSP 之间)相关。 如果我清除 kmemleak 日志并让系统运行一段时间、我不会显示进一步的错误。 您是否看到类似结果?

    我正在咨询我们的内核开发人员、以获取他们对此的意见、并应尽快提供更多详细信息。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Ronb、

    正如您所说的、清除 kmemleak 日志后、您不会再遇到进一步的内存泄漏。 我还使用 命令# echo clear >/sys/kernel/debug/kmemleak 清除了日志、它不会显示进一步的泄漏。

    但我在 Linux Documentation for kmemhun泄漏 中发现、上述命令(echo clear > /sys/kernel/debug/kmemleak)会清除 当前内存泄漏列表。

    然后、再次读取/sys/kernel/debug/kmemleak (而不是之前的泄漏)时、将出现新泄漏(如果存在)。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Vikash、

    我已经向我们的开发人员确认这些都是误报。 他需要了解为什么 kmemleak 在抱怨、并在将来的更新中将这些分配标记为忽略。

    Remoteproc 在初始启动期间加载和引导,并为 IOMMU 页表条目分配其中的一些块缓存条目。 当您停止远程处理器时、它们会被释放。 因此、这些存储器的真正泄漏应检查加载/启动和关断组合前后的行为。

    在我运行的测试中(听起来与您的测试类似)、远程处理器(例如 DSP)已启动并正在运行(或正在等待某项操作)。 只有当正确关闭这些存储器时、才会释放该存储器。

    清除日志有助于验证这一点、并确保当前运行的任何其他操作都不会导致问题。

    因此、我们将在未来努力确保这些不会出现、但它们不会对系统产生负面影响。