Обнаружение и анализ утечек памяти ядра с помощью kmemleak

Что обнаруживает kmemleak в ядре

Кмемлейк поддерживает отладку ядра Linux, выполняя поиск потенциально «заброшенных» объектов памяти. Для этого он отслеживает поддерживаемые выделения памяти и проверяет, обнаруживаются ли в просканированных областях памяти ссылки на эти объекты. Объект, который не был признан доступным, отображается как возможная утечка памяти, а не как окончательно подтверждённая ошибка.

Представь, что модуль ядра резервирует объект, а затем теряет последнюю ссылку на него, не освободив память. Если kmemleak при своей Поиск ссылок если больше нет никаких ссылок на этот объект, он может пометить его как подозрительный. Это сообщение дает отправную точку для анализа размещения и предусмотренного жизненного цикла в коде.

Этот алгоритм похож на поиск доступности, осуществляемый сборщиком мусора, но не выполняет его функции очистки: Kmemleak не освобождает обнаруженные объекты и не исправляет код. Вопрос о том, действительно ли объект утрачен, необходимо выяснять на основе его использования, отношений владения и предусмотренного порядка освобождения.

Утечка ядра касается памяти, управляемой кодом ядра или модулем. Утечка в сервисе PHP или другом процессе пользовательского пространства относится к другому классу ошибок; kmemleak не проверяет его кучу. Для более широкого Обнаружение утечек памяти в хостинговой среде Поэтому в качестве дополнительных средств можно рассмотреть данные о процессе и другие диагностические инструменты.

Само по себе увеличение объема занятой оперативной памяти не является доказательством Утечка памяти или его местоположение. На потребности могут повлиять также изменение объема работ или более длительное хранение данных. Поэтому разумной отправной точкой является процесс, который можно ограничить по времени и функциональности и в рамках которого можно целенаправленно проверить подозрение, связанное с ядром.

Почему сообщения остаются лишь подозрениями

Поиск значений указателей не всегда может распознать все значения, которые программа присваивает ссылке. Если действительная ссылка находится за пределами сканируемых областей или хранится таким образом, что kmemleak не может её распознать, объект, который по-прежнему необходим, может отображаться как «заброшенный». Это один из возможных Ложная тревога: Само по себе это сообщение не доказывает, что разрешение отсутствует.

Возможно и обратное. Числовое значение может случайно выглядеть как указатель на объект, хотя в коде оно не используется в качестве ссылки. В таком случае Kmemleak может классифицировать этот объект как доступный и пропустить настоящую утечку памяти. Поэтому пустой вывод не является доказательством того, что проверяемый код не содержит ошибок.

К этому следует добавить объем выполняемых операций выделения памяти: прямые операции выделения страниц и ioremap согласно документации ядра, не отслеживаются. Если у кого-то возникли подозрения о росте потребления памяти в этих областях, он не может сделать вывод об отсутствии данной причины на основании незаметного отчета kmemleak. Для этого необходимо провести другое исследование.

Die Доступность Таким образом, это техническая эвристика, а не полный семантический анализ программы. Она не даёт достоверного ответа на вопрос, используется ли обнаруженная ссылка целесообразно или же пропущенная ссылка действительно отсутствует. Каждое обнаружение представляет собой задачу проверки; отсутствие обнаружений лишь ограничивает информативную ценность данного сканирования.

Для оценки ситуации стоит повторно воспроизвести подозрительную ситуацию в контролируемых условиях, а затем проанализировать соответствующий путь выполнения кода. В частности, необходимо выяснить, кому принадлежит объект и когда он должен быть освобожден. Только такое исследование может дать правдоподобное объяснение полученным результатам.

Проверка тестовой среды и требований

Документация по версии Linux 6.6 служит здесь технической отправной точкой. Однако наличие утечки kmemleak в вашей системе зависит от используемой сборки ядра и его конфигурации, а не только от номера версии. Поэтому проверьте, какое именно ядро дистрибутива установлено, и запишите его сборку и конфигурацию для последующего анализа.

Одним из необходимых условий является включение соответствующего параметра ядра при компиляции CONFIG_DEBUG_KMEMLEAK. От этого следует отличать Активация во время выполнения: Установлен ли ядро с CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF настроен, то параметр загрузки kmemleak=on может потребоваться. Обязательно предусмотрите изменения в процессе загрузки специально для утвержденной тестовой конфигурации.

Для доступа к диагностическому интерфейсу необходимо также debugfs должны быть доступны и соответствующим образом подключены. Конфигурация ядра, активация и доступ к файловой системе — это разные контрольные точки: одно лишь отсутствие интерфейса ещё не указывает, какая из них является причиной. Для доступа могут потребоваться привилегированные права.

По возможности используйте изолированную виртуальную машину или выделенную тестовую систему и заранее согласуйте разрешение на внесение изменений. Kmemleak приводит к дополнительным затратам ресурсов при выделении и освобождении памяти; степень влияния зависит от среды и нагрузки. Без соответствующих измерений невозможно указать универсальное снижение производительности.

Помимо ядра, задокументируйте также исследуемый модуль, запланированный ход работы и момент вывода данных. Диагностические отчеты могут содержать внутренние адреса и другую конфиденциальную информацию. Храните их в месте с ограниченным доступом и перед передачей проверьте, какие данные действительно необходимы для анализа ошибок.

Интерфейс и диагностические команды

Начните на развернутой тестовой системе с доступа только для чтения к /sys/kernel/debug/kmemleak. В этом файле отображаются текущие зарегистрированные подозрительные случаи. Для доступа к нему могут потребоваться специальные права; пустой вывод отражает лишь видимое диагностическое состояние и не подтверждает, что ядро не содержит утечек памяти.

Выполните следующую команду в командной оболочке с достаточными правами на чтение. Она не изменяет диагностический статус и также подходит для сохранения первоначальных результатов перед дальнейшими действиями.

cat /sys/kernel/debug/kmemleak

Если файл отсутствует, можно выделить три возможные причины: возможно, ядро было установлено без CONFIG_DEBUG_KMEMLEAK Скомпилировано, kmemleak не активирован во время выполнения или debugfs не смонтирован в ожидаемом месте. Сам по себе отсутствующий файл не позволяет определить, какой из этих вариантов верный. Поэтому проверьте конфигурацию сборки, конфигурацию загрузки и монтирование по отдельности.

В таблице намеренно проводится различие между чтением и Права на запись: Сканирование и очистка видимого списка влияют на диагностический статус. Подключение mount debugfs, если это необходимо, также вносит изменения в систему. Выполняйте такие действия только с разрешения и при наличии необходимых прав; для перенаправления команд записи также требуются соответствующие права.

Определение подозрительных случаев с возможностью воспроизведения результатов

Сначала сохраните полный вывод интерфейса вместе с датой и временем, версией ядра и конфигурацией тестирования. Уже имеющиеся сообщения относятся к Исходные данные и не должны безосновательно приписываться следующему тесту. Храните вывод в надежном месте, так как он может содержать внутренние адреса и другую диагностическую информацию.

На открытой для доступа тестовой системе ты можешь затем удалить текущие видимые сообщения из списка подозрительных с помощью следующей команды оболочки. Оболочке требуются права на запись в интерфейс. Эта команда не освобождает блоки памяти и не устраняет причину проблемы; без предварительного резервного копирования важная информация может быть утеряна.

echo clear > /sys/kernel/debug/kmemleak

Затем запустите как можно более четко ограниченный и задокументированный процесс, например, инициализацию и контролируемую очистку модуля, подлежащего исследованию. Зафиксируйте, какие шаги были выполнены и когда они были завершены. Таким образом, впоследствии обнаруженную проблему можно будет более конкретно соотнести с этим процессом, не допуская, чтобы лишь временная близость сама по себе свидетельствовала о причинно-следственной связи.

По истечении времени запустите сканирование в оболочке с соответствующими правами, а затем повторно прочтите интерфейс. Обе команды предполагают, что kmemleak активен и интерфейс debugfs доступен.

echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak

Повторите процедуру, тщательно контролируя каждый шаг, и уделите этому достаточно времени. Сканирование не обязательно сразу даст воспроизводимые результаты. Для регрессионного тестирования сравните результаты одного и того же теста до и после изменения кода при максимально одинаковой конфигурации ядра и нагрузке; задокументируйте оставшиеся различия. Новое подозрение подтверждает гипотезу, но не заменяет проверку жизненного цикла объекта.

Тестирование модулей и анализ результатов

При тестировании модуля ты можешь, например, выполнить путь инициализации, а затем пройти предусмотренный путь очистки. Если после этого появляется новая запись, сначала запишите размер объекта, его возраст и контекст процесса, а также соответствующие этапы тестирования. Эти данные помогут соотнести результаты; сами по себе они ещё не показывают, действительно ли объект должен был быть освобождён.

Der Стек трассировки распределения приводит к месту, где был запрошен объем памяти. Оттуда ты можешь проследить в коде, кто принимает объект и по какому пути он должен быть освобожден. Трассировка не обязательно должна содержать место, где не было выполнено освобождение памяти: выделение памяти и пропущенная очистка могут происходить в разных функциях.

Учти также Порядок распределения: В документации порядок вывода сообщений описан именно в таком порядке. Предыдущий заброшенный объект может повлечь за собой появление дальнейших сообщений. Поэтому прежде чем считать их отдельными дефектами, проверьте, не относятся ли несколько записей к одному и тому же набору объектов или пути ошибки.

Для проведения дополнительной проверки работоспособности в текущей документации по ядру описан модуль kmemleak-test, который намеренно создает утечки памяти. Используйте его исключительно в изолированной тестовой среде и предварительно проверьте, доступен ли он в конкретном ядре и правильно ли он настроен. Текущая документация не гарантирует его доступность для всех устаревших ядер или ядер, специфичных для определённых дистрибутивов.

Даже в случае этого диагностического модуля не гарантируется немедленное появление сообщения или обнаружение неисправности при первом сканировании. Запишите время проведения теста и последовательность сканирования, а затем повторите проверку в контролируемых условиях. Если сначала вывод остаётся пустым, проверьте исходные условия и порядок действий, а не делайте выводы о работоспособности или неисправности диагностической среды только на основании этого.

Проверить причину, а не скрывать сообщение

В случае подозрения начните с анализа жизненного цикла заявленного объекта: какую функцию он резервирует, кто впоследствии принимает на себя ответственность и когда он должен быть освобожден? Стек трассировки выделения памяти приведёт вас к источнику резервирования. Определить, находится ли ошибка именно там или в более позднем месте, можно только на основе траектории выполнения кода.

Обратите особое внимание на Структура собственности при передаче данных между функциями и модулями. При передаче ссылки должно быть ясно, какая сторона её сохраняет, а какая — освобождает. Кроме того, сравните стандартный путь очистки с путями прерывания и обработки ошибок, например, когда инициализация завершается лишь частично.

Сообщение об ошибке может появляться даже при наличии действительной ссылки, которую kmemleak не распознает. Поэтому, прежде чем подавлять это сообщение, проверьте, где и в каком виде хранится указатель. Задокументируйте, почему объект остается доступным в течение всего своего предполагаемого срока жизни и каким образом он в конечном итоге освобождается.

Для проверенных особых случаев разработчикам предоставляются Аннотации в наличии: kmemleak_not_leak помечает известный объект как не содержащий утечки, но продолжает сканировать его на наличие ссылок. kmemleak_ignore исключает объект как из отчета, так и из сканирования. В результате в анализе могут отсутствовать ссылки, содержащиеся в этом объекте.

Проверьте доступность и семантику API в фактически используемом ядре; актуальная документация по API не является автоматической гарантией для каждой более старой сборки. Аннотация не устраняет ни отсутствующее разрешение, ни некорректную смену владельца. Поэтому не используйте её в одиночку для устранения мешающего вывода.

Диагностика неисправностей и безопасная эксплуатация

Файл отсутствует /sys/kernel/debug/kmemleak, сначала проверьте, какая сборка ядра была фактически запущена, и её конфигурацию. CONFIG_DEBUG_KMEMLEAK должно быть указано; одного только номера версии дистрибутива для этого недостаточно. Зафиксируйте сборочную версию и конфигурацию, чтобы последующие сравнения проводились на одинаковой основе.

Кроме того, проверьте Активация во время выполнения и подключение debugfs. При CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF параметр загрузки может kmemleak=on может потребоваться. Отсутствующий файл сам по себе не позволяет различить эти возможные причины; изменения в процессе загрузки или подключение mountpoint debugfs должны осуществляться в рамках утвержденной тестовой конфигурации.

Если после теста вывод остаётся пустым, проверьте, действительно ли исследуемый процесс был запущен и было ли достаточно времени между запуском процесса и сканированием. Повторите тест в задокументированных условиях и сравните результаты с сохраненными исходными данными. Даже в этом случае пустой отчёт имеет ограниченную ценность: kmemleak не фиксирует не каждую аллокацию и не каждую значимую ссылку.

Сохраните имеющиеся данные до внесения изменений в диагностический статус. Вывод может содержать внутренние адреса и другую конфиденциальную информацию; обрабатывайте его в соответствии с правилами доступа и публикации, действующими в вашей среде. Предпочтительно выполняйте действия, изменяющие состояние, на изолированной, предоставленной для тестирования системе и учитывайте дополнительные затраты на диагностику, не принимая для этого необоснованных процентных значений.

Высокие требования к объему памяти или Нагрузка на память является самостоятельной проблемой работы системы и сама по себе не является доказательством утечки ядра. Для оценки времени ожидания и нехватки памяти полезно ознакомиться со статьёй по теме Нагрузка на память в ядре Linux. Совмещайте такие наблюдения за работой с целенаправленной проверкой кодов и результатов диагностики, вместо того чтобы делать выводы о причине непосредственно на основании кривой RAM.

Выбор подходящего диагностического инструмента

Выбери инструмент в соответствии с предполагаемой Класс ошибок, а не только по общему признаку — увеличению использования памяти. kmemleak ищет потенциально заброшенные, поддерживаемые объекты ядра. Для выявления неправомерных обращений или проблем с памятью пользовательского процесса целесообразно использовать другие инструменты; эти инструменты отвечают на разные вопросы.

Подозрение на утечку ссылки на ядро в первую очередь указывает на kmemleak. Если же картина ошибки свидетельствует о доступе за пределы объекта или к уже освобожденной памяти, для анализа данного класса ошибок подходит KASAN. KFENCE также отслеживает определённые ошибки памяти, но использует другой подход к инструментированию; его доступность и пригодность зависят от конкретного ядра и тестовой среды.

Если подозрение падает на процесс пользовательского пространства, проверьте его память с помощью специального инструмента, такого как Valgrind Memcheck. Отчет kmemleak об объектах ядра не заменяет анализ кучи приложения. И наоборот, указание из пользовательского процесса не означает автоматически, что модуль ядра теряет память.

Для дальнейшей работы выбери один из следующих вариантов воспроизводимый тест и зафиксируйте процесс сборки ядра, его настройку и ход работы. Изучите указанный жизненный цикл объекта в коде, устраните выявленную причину и повторите тот же процесс в максимально одинаковых условиях. Снова сравните полученные результаты; само по себе отсутствие сообщения об ошибке ещё не доказывает полного отсутствия ошибок.